Re: Exponential operator
Miles wrote: Don wrote: You didn't respond to my assertion: even if you _could_ do it, why would you want to? ** sucks as an exponential operator. I dispute the contention that ** is a natural choice. It comes from the same language that brought you IF X .NE. 2 There are too many languages that support ** as an exponentiation operator, that is the reason ** is a likely candidate. Your reasoning seemed to be: - Fortran is bad; - Fortran had ** as its exponentiation operator; - So, ** is bad as an exponentiation operator. Not at all! I'm attacking the fallacy that ** must be a good choice because so many languages use it. * The ONLY reason other languages use ** is because Fortran used it. * Fortran used ** because it had no choice, not because it was believed to be good. * We have choices that Fortran did not have. The best choice for Fortran is not necessarily the best choice for D. Note that there are no C-family languages which use ** for exponentiation, so there isn't really a precedent. However, the syntax is really not the issue. The issue is, is there sufficient need for a power operator (of any syntax)? I don't care for ** or .NE., really. I don't like * as a multiplication operator, in fact. I'd rather have × as multiplication, ↑ as exponentiation, ∧ as logical and, ∨ as logical or, ¬ as a logical not, = as equality, ≠ as inequality and ← as assignment. I don't know why, but every time I say this, it brings all sorts of controversies and euphoric reactions. Lack of keyboards.
Properties, opIndex, and expression rewriting.
http://www.igsoft.net/dpolls/poll/results.php?pollid=1
* 111 votes total.
* Keep things as they are now: 1 vote.
* And where did that vote come from?
Jeremie Pelletier pisze:
Oops, I got the only one keep things as they are now vote haha.
I meant to vote for the one with resolved +=.
So, Walter, how about some expression rewriting logic to solve some of
the problems with properties, opIndex, and related lvalueness stuff?
(I refer to the expression rewriting in the Wiki4D article on
properties:
http://prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semantic)
Syntax can be broached later.
I've also attached some D-like pseudocode of what I think such an
expression rewriting algorithm would look like (propertyrewrite.d). The
other file is a potential test-case. I used it to figure out what a
trace of the algorithm might look like, and designed it accordingly. If
it can wait a few weeks, I might try to put it into dmd and write a
patch. I'll only do it if there's interest though.
Other notes about attached pseudocode:
* The types in this psuedocode are expected to be defined as D classes
are; that is, they are reference types.
* It seems worthwhile to call this after operator overloads are turned
into calls. This would make it more clear which things potentially have
side effects. (Just imagine how is overloaded in C++. As much as
it's frowned upon, something similar could happen in the future of D.
Marking overloads like '', '+', '-' as pure could potentially remove
any pessimisation.)
// This function will take the expression expr and expand it into multiple
// statements such that no single statement contains more than one side-
// effect. It will also scan for property getter invocations and opIndex
// that are treated as lvalues. When it finds them, it will rewrite them
// such that the corresponding setter or opIndexAssign is guaranteed to be
// called.
//
// To provide some insight into how prolog and epilog work, here is what they
// look like at the outermost level:
// [prolog]
// auto t0 = a;
// [prolog and epilog grow towards the center]
// a++;
// a = t0;
// [epilog]
// (That would be made from a++; if 'a' were a property.)
//
// Assumptions:
// * expr's structure is consistent with operator precedence.
// * Operator overloads have already been expanded into function calls.
//
Expression doPropertyRewriteGreedily(
Expression expr,
BlockStatement prolog,
BlockStatement epilog,
bool hasSideEffects // Does the parent expression have side-effects?
)
{
VariableExpression temporary = expr;
if ( expr == opPostInc || expr == opPostDec )
{
// Generate any temporaries that we depend on but don't know about.
// Also, find out what the child is made of.
auto incoming =
doPropertyRewriteGreedily(expr.child,prolog,epilog,true);
if ( incoming.isVariableExpression() )
{
// The rewrite gave us a variable or a temporary, so making
// yet another temporary is unnecessary.
temporary = incoming;
}
else
{
// Make a new temporary to hold the returned expression.
temporary = new VariableExpression(makeUniqueTemporaryName());
// Check for duplicate getter calls before injecting ours.
if ( ! prolog.contains(auto {anything} = {incoming};);
prolog.append(auto {temporary} = {incoming};);
}
// Check for duplicate setter calls before injecting ours.
if ( ! epilog.contains({incoming} = {anything};) )
epilog.prepend({incoming} = {temporary};);
// This looks out-of-order, but since we are prepending,
// this will actually be executed before the setter is called.
expr.child = temporary;
epilog.prepend({expr};);
}
else if ( expr == oneOf(~,!,-,+=,-=,*=,/=,%=,|=,=,~=,=,=,=)
|| expr == impureFunctionCall )
{
// lhs = left-hand-side. rhs = right-hand-side.
// For the unary ~, !, and -, the lhs is the argument
// and the rhs has zero expressions.
auto lhs = expr.lhs;
// Generate any temporaries that we depend on but don't know about.
// Also, find out what the left-hand-side is made of.
auto incoming = doPropertyRewriteGreedily(lhs,prolog,epilog,true);
if ( incoming.isVariableExpression() )
{
// The rewrite gave us a variable or a temporary, so making
// yet another temporary is unnecessary.
temporary = incoming;
}
else
{
// Make a new temporary to hold the returned expression.
temporary = new VariableExpression(makeUniqueTemporaryName());
// Check for duplicate getter calls before injecting ours.
if ( ! prolog.contains(auto {anything} = {incoming}; )
prolog.append(auto {temporary} = {incoming};);
Re: Compile time code paths
Jeremie Pelletier wrote:
David Gileadi Wrote:
Daniel Keep wrote:
Jeremie Pelletier wrote:
If a function has both an asm and D implementations inside its body, and the D
version can be executed at compile time, but the asm one is much faster at
runtime. Is it possible to have the compiler use the D code path at compile
time (ie to fill in enums and whatnot), and have the asm version available at
runtime.
Not that I know of. There's no way to switch based on run time/compile
time. This was going to be solved, at least in part, using static
arguments, but that got dropped.
As it stands, you just have to use a suffix or prefix or something to
distinguish CTFE methods from runtime methods.
Is this a case for version(CompileTime){}?
No because it would also compile this block into the binary.
I think something like this might work:
static if (__traits(CompileTime)) {
... // ctfe code
} else {
asm {
...
}
}
Not sure what the exact syntax should be.
The easy way is of course to have different symbols for compile-time and
run-time. But this doesn't go well with generic programming where the function
needing such a check can be deep in the compile-time call stack.
For example:
int foo() { return bar + 1; }
int bar() { return foobar * 2; }
int foobar() {
static if(isCompileTime) return ...; /// asm cannot execute at compile time,
needed to keep foo and bar able to do CTFE
else asm { ...; } /// asm optimized for runtime
}
Re: GPU/CPU roadmaps
bearophile wrote: D2/D3 may become a good language to create video games, this is a new interesting document that shows some of the things D2 users may want to use it for: http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf I don't know how D2 can adapt itself to help in such regards. Bye, bearophile Do you think the D language needs to adapt more for this market? From my limited perspective, I see numerous things D does, especially in the concurrency department, that is on the list of requirements put forth in that presentation. Furthermore, it's interesting to note some of the numbers pertaining to GOW 2: 250K LoC for the game and 2000K LoC for the engine, excluding loads of libraries like speedtree, openal, etc. So middleware is key right? Especially by providing easier ways to program difficult architectures. Now this again is something that D can do well, it's very suitable for building good libraries. Now here is the problem too, they have to be build. Concluding remark of the presentation says that if you start building an engine now, you finish in 2014. I don't think D has a chance on this scale of game development when it faces competition from such monster engines in C++. To return to your original question: what about the systems programming aspects of D? For example, cutting out the GC and typeinfo bloat, dealing with arrays, whatever. Is this something that good library developers can do just on their own or do we need some more support for this? I was thinking what it would take to develop a specialized component in D that can be used from within a demanding C/C++ ecosystem.
Re: reddit.com: first Chapter of TDPL available for free
Jeremie Pelletier wrote: Andrei Alexandrescu Wrote: Steven Schveighoffer wrote: On Mon, 03 Aug 2009 18:00:59 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/ (Don't tell anyone, but I plan to rewrite it.) Andrei Wow, my head's spinning :) That's a lot of data/concepts in one chapter. Have you considered how this chapter will be for a newbie programmer? Like KR, TDPL is intended for people who already know how to program in another language. Knowledge of a specific language is not recommended or required. The preface will make that clear. Some reviewers are still concerned that I discuss topics a bit too advanced in the first chapter. I was suggested to adapt The Case for D instead of this first chapter. *disclaimer: I'm not an expert on teaching or writing books. Well you are an expert on reading books and that's what matters here. Andrei I agree that your preview, while being really insightful into D, is gonna make the head of beginners explode. For example, you dive rather headfirst into variables, using immutable and auto before even talking about variable types. I for one believe the market for such a book is mostly beginner to intermediate programmers. I only needed the language reference on the digitalmars website to learn about the syntax and semantics of D, and reading the code in the runtime and phobos gave more than enough examples to get comfortable using the language. I think it's a hard problem: how do you write a book that's accessible to beginners without alienating experienced programmers? I'm personally of the mindset that beginners should most definitely not be attempting to learn D as their first language. Languages like D, C, C++ are horribly unsuitable because they force you to understand how the machine works before you can learn to program; except that they force you to learn to program in order to understand how the machine works. I've seen too many *university students* (and we're talking second and third year students) struggling with both because they don't quite understand how the machine works and don't quite understand how C works; the two work together to sabotage their understanding. I think something like Python or even, yes, BASIC is more appropriate because it reduces the size of the problem down to how do I correctly sequence the actions I want the computer to perform, and how do I express those actions? I personally don't think TDPL should worry too much about absolute beginners; they'll be better served by a different type of book for a different type of language. That, and they'll take one look at templates and run screaming. I still have trouble explaining the difference between compile-time arguments and run-time arguments to experienced programmers, let alone novices!
Re: GPU/CPU roadmaps
Chad J: I'd love to see that, though I worry that the existing C++ codebase (mostly in middleware) is too momentous. It's like garbage trucks on ice. They spend lot of work and money on such code. I don't think they are so fixed on C++. So I think they are willing to change languages (to D) if they see D as good enough for their purposes. They need a compiler able to produce efficient code (LDC is almost there), a profiler, debugger, code coverage, a well debugged language. Some editor support for D (a really good IDE isn't strictly necessary). First of all they need a language that's able to do in a simple way what they need, this means using Intel Larrabee efficiently and GPUs in a simple enough way. A language that's not designed to replace scripting languages (like Lua, Python, etc) but to work well beside them. A language that allows to use software transactional memory in a handy way, and to use a lot of data parallelism instructions efficiently and with a good enough syntax. A language that's safer, with less corner cases and that allows to write concurrent code that's much less buggy (here the type system helps a lot, like the non-nullability by defaulf of class references). Currently the D2 language isn't much designed for such things. Give them such things and I think they are willing to leave C++ for D in a short time :-) Bye, bearophile
Void-safety (and related things)
Found on Lambda the Ultimate blog, Void-safety in Eiffel language, another attempt at solving this problem: http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf I think to solve this problem a language like D can use three different strategies at the same time. Three kinds of object references can be defined: 1) the default one (its syntax is the shorter one, they are defined using the like current ones) is the non nullable object reference. Many objects in a program are like this. The type system assures the code to be correct, you don't need to test such references for null. As in C# the compiler keeps eyes open to avoid the usage of uninitialized references of such kind. (this is a situation where good is better than perfect. C# seems to work well enough in its ability to spot uninitialized variables). 2) The second kind is the current one, unsafe nullabile object reference, it's faster, its syntax is a bit longer, to be used only where max performance is necessary. 3) The third kind is the safe nullabile object reference. You can define it like using the syntax Foo? f;. It's a fat reference, so beside the pointer this reference contains an integer number that represents the class. If your program has 500 classes, you need 500 different values for it. On the other hand usually in a program a specific reference can't be of 500 different classes, so the maximum number can be decreased, and you can keep at runtime sono conversion tables that convert some subsets of such numbers into a full pointer to class info. Such tables are a bit slow to use (but they don't need too much memory), but the program uses them only when a reference (of the third kind) is null, so it's not a bit problem. On 64-bit systems such numeric tag can be put into the most significant bits of the pointer itself (so when such pointer isn't null you just need a test and a mask, the shift is required only in the uncommon case of null). This also means that the max ! number of possible class instances decreases, but not so much (you can have some conversion tables to reduce such such numeric tag to 2-5 bits in most programs). When the code uses a method of a null reference of such kind the program may call the correct method of a default instance of that class (or even a user-specified instance). Do you like? :-) Bye, bearophile
Re: T[new]
Jarrett Billingsley: I don't see why that's a big problem. Like St Thomas I touch first and believe (maybe) later :-) Bye, bearophile
Re: Exponential operator
Don Wrote: However, the syntax is really not the issue. The issue is, is there sufficient need for a power operator (of any syntax)? std.math.pow only support floating point number http://d.puremagic.com/issues/show_bug.cgi?id=2973 If we can't make the power function more powerful, yes, we need a new operator.
Re: Exponential operator
On 2009-08-10 13:56:53 -0400, Miles ...@___. said: Don wrote: You didn't respond to my assertion: even if you _could_ do it, why would you want to? ** sucks as an exponential operator. I dispute the contention that ** is a natural choice. It comes from the same language that brought you IF X .NE. 2 There are too many languages that support ** as an exponentiation operator, that is the reason ** is a likely candidate. Your reasoning seemed to be: - Fortran is bad; - Fortran had ** as its exponentiation operator; - So, ** is bad as an exponentiation operator. I don't care for ** or .NE., really. I don't like * as a multiplication operator, in fact. I'd rather have × as multiplication, ↑ as exponentiation, ∧ as logical and, ∨ as logical or, ¬ as a logical not, = as equality, ≠ as inequality and ← as assignment. HyperTalk used to have for inequality, but ≠ worked too. You could write = for greater or equal, but ≥ worked too. That said, having = as equality in a C-derived language is somewhat problematic. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: GPU/CPU roadmaps
Tue, 11 Aug 2009 00:37:46 -0400, Jeremie Pelletier thusly wrote: I wouldn't be surprised to see major games releases built in D in a few years. It's quite optimistic to think that the toolchain will be usable and robust enough on the large scale in a few years. For instance adding the keywords immutable, const, and pure will not magically turn D into the state of the art research language in the category of pure functional languages.
Re: reddit.com: first Chapter of TDPL available for free
Tue, 11 Aug 2009 19:04:50 +1000, Daniel Keep thusly wrote: I'm personally of the mindset that beginners should most definitely not be attempting to learn D as their first language. Languages like D, C, C++ are horribly unsuitable because they force you to understand how the machine works before you can learn to program; except that they force you to learn to program in order to understand how the machine works. One way to teach languages with both high and low level concepts is to start bottom-up. Surely the high level concepts are usually built from atomic low level artifacts. This would even be a good design method for the whole language. It's much easier to reason about the language if the core is kept simple. It's also a practical way to organize your thoughts by separating the semantics from the syntax and seeing its composite nature.
Re: Void-safety (and related things)
I've recently convinced myself that nullability should be the exception instead of the norm. So much of the code I write in C#/D uses reference objects assuming they're non-null. Only in certain special cases do I handle null explicitly. The issue is that if any special case is missed/mishandled, it can spread to other code. I'm also too lazy to write non-null contracts in D. They also have far less value since violations are not caught at compile time (or better yet, in my IDE as I write code). It may be as simple as having the following 3 types: T // non-nullable T? // nullable, safe T* // nullable, unsafe I'd also like to remove all default initialization in favor of use of uninitialized variable errors. Default initialization in D is cute, but it is not a solution for programmer oversight. Single-threaded code will reproducibly do the wrong thing, but may be harder to notice in the first place. The very fact that the signalling nan change has made it into D shows that people want this type of behavior! bearophile Wrote: Found on Lambda the Ultimate blog, Void-safety in Eiffel language, another attempt at solving this problem: http://docs.eiffel.com/sites/default/files/void-safe-eiffel.pdf I think to solve this problem a language like D can use three different strategies at the same time. Three kinds of object references can be defined: 1) the default one (its syntax is the shorter one, they are defined using the like current ones) is the non nullable object reference. Many objects in a program are like this. The type system assures the code to be correct, you don't need to test such references for null. As in C# the compiler keeps eyes open to avoid the usage of uninitialized references of such kind. (this is a situation where good is better than perfect. C# seems to work well enough in its ability to spot uninitialized variables). 2) The second kind is the current one, unsafe nullabile object reference, it's faster, its syntax is a bit longer, to be used only where max performance is necessary. 3) The third kind is the safe nullabile object reference. You can define it like using the syntax Foo? f;. It's a fat reference, so beside the pointer this reference contains an integer number that represents the class. If your program has 500 classes, you need 500 different values for it. On the other hand usually in a program a specific reference can't be of 500 different classes, so the maximum number can be decreased, and you can keep at runtime sono conversion tables that convert some subsets of such numbers into a full pointer to class info. Such tables are a bit slow to use (but they don't need too much memory), but the program uses them only when a reference (of the third kind) is null, so it's not a bit problem. On 64-bit systems such numeric tag can be put into the most significant bits of the pointer itself (so when such pointer isn't null you just need a test and a mask, the shift is required only in the uncommon case of null). This also means that the ma! x number of possible class instances decreases, but not so much (you can have some conversion tables to reduce such such numeric tag to 2-5 bits in most programs). When the code uses a method of a null reference of such kind the program may call the correct method of a default instance of that class (or even a user-specified instance). Do you like? :-) Bye, bearophile
Re: Memory allocation problem
Mon, 10 Aug 2009 14:15:41 -0400, bearophile thusly wrote: Steven Schveighoffer: My point is, don't count on having 2GB of usable space even if you physically have 2GB of RAM, it may not be the case. I was looking for using 1.8 GB not 2. Better off to not desire than to complain about edge conditions based on hardware limitations. With C I can use up to about 1.94 GB of RAM, I don't think 1.8 is so on the edge :-) I think this is a bug of DMD, it's not a problem of my PC. You can also try to buy another 2 GB of RAM and see if the problem persists. On a machine with 4 GB of physical RAM, a 32-bit OS usually can see ~3..3.5 GB free. I even think that if your OS supports page files, it doesn't matter if the memory is on chip or disk - if the memory is split 3/1 for processes and kernel, you should be able to allocate 2 GB easily.
Re: Memory allocation problem
Tue, 11 Aug 2009 12:58:59 +, language_fan thusly wrote: I even think that if your OS supports page files, it doesn't matter if the memory is on chip or disk - if the memory is split 3/1 for processes and kernel, you should be able to allocate 2 GB easily. For example my system has 5GB of virtual memory reported by the OS, and 3.5GB free virtual space, 1.6GB free physical RAM. The OS provides a memory space of 3GB for each process. Based on some testing C allows allocating a maximum amount of 2810MB RAM with malloc.
Re: Void-safety (and related things)
Jason House wrote: I've recently convinced myself that nullability should be the exception instead of the norm. So much of the code I write in C#/D uses reference objects assuming they're non-null. Only in certain special cases do I handle null explicitly. The issue is that if any special case is missed/mishandled, it can spread to other code. I'm also too lazy to write non-null contracts in D. They also have far less value since violations are not caught at compile time (or better yet, in my IDE as I write code). It may be as simple as having the following 3 types: T // non-nullable T? // nullable, safe T* // nullable, unsafe I'd also like to remove all default initialization in favor of use of uninitialized variable errors. Default initialization in D is cute, but it is not a solution for programmer oversight. Single-threaded code will reproducibly do the wrong thing, but may be harder to notice in the first place. The very fact that the signalling nan change has made it into D shows that people want this type of behavior! Yes. Default initialization is really week against uninitialized variables errors. You notice the errors of the first one at runtime, and the errors of the second one at compile-time. But I don't see that changing anytime soon... (I think it's because it gets hard).
Re: reddit.com: first Chapter of TDPL available for free
language_fan wrote: Tue, 11 Aug 2009 19:04:50 +1000, Daniel Keep thusly wrote: I'm personally of the mindset that beginners should most definitely not be attempting to learn D as their first language. Languages like D, C, C++ are horribly unsuitable because they force you to understand how the machine works before you can learn to program; except that they force you to learn to program in order to understand how the machine works. One way to teach languages with both high and low level concepts is to start bottom-up. Surely the high level concepts are usually built from atomic low level artifacts. This would even be a good design method for the whole language. It's much easier to reason about the language if the core is kept simple. It's also a practical way to organize your thoughts by separating the semantics from the syntax and seeing its composite nature. It sounds good in theory, but it doesn't seem to hold up in practice.
Re: reddit.com: first Chapter of TDPL available for free
Wed, 12 Aug 2009 00:06:03 +1000, Daniel Keep thusly wrote: It sounds good in theory, but it doesn't seem to hold up in practice. Why? Has there been any non-successful attemps in this direction? Many constructs of D for which semantics can be defined with a collection of simpler constructs come to mind, e.g. foreach.
Re: Void-safety (and related things)
Ary Borenszweig: (I think it's because it gets hard). You can't ask a single person to be able to do everything. Are you able to implement that thing? Probably I am not able. If someone here is able and willing to do it then I suggest such person to ask Walter permission to implement it. Bye, bearophile
Re: reddit.com: first Chapter of TDPL available for free
language_fan wrote: Wed, 12 Aug 2009 00:06:03 +1000, Daniel Keep thusly wrote: It sounds good in theory, but it doesn't seem to hold up in practice. Why? Has there been any non-successful attemps in this direction? Many constructs of D for which semantics can be defined with a collection of simpler constructs come to mind, e.g. foreach. I used lowering to explain the likes of foreach and scope(xyz), with what I'd call qualified success. It doesn't simplify things as much as one would think it does. Andrei
Re: Explicitly saying ref or out when invoking a function
Ary Borenszweig wrote: In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); When I first started using C# it really annoyed me that I had to put that keyword there just to get my program compiled. I know what I'm doing, I thought. But later, when reading the code, I found it very helpful to know that my a could be changed when invoking fun. As always, code is read much more times than written, and I think this little tips help better understand the code. What do you think? I'm not sure. However, you could implement something like this in descent without having to type all that or change D ;) Change the color of the parameter or something like that...
Re: Explicitly saying ref or out when invoking a function
Ary Borenszweig: What do you think? I don't know. It's a different design choice. Generally explicit is better and safer, but I don't know much safer this is. Overall I think the C# choice here is a bit better, but you have to write lot of code before being able to tell C# has chosen for the better. Another similar design choice is that in C# a method that overrides another one must have the attribute override, while in D it's optional. Now in C#4 you can omit the ref in the call point if it's a COM type, this leads to tricks: http://msmvps.com/blogs/jon_skeet/archive/2009/07/07/faking-com-to-fool-the-c-compiler.aspx Bye, bearophile
Re: Explicitly saying ref or out when invoking a function
Reply to Ary,
In C# when you define a function that takes an out or ref parameter,
when invoking that function you must also specify ref or out. For
example:
void fun(ref uint x, double y);
uint a = 1;
double b = 2;
fun(ref a, b);
When I first started using C# it really annoyed me that I had to put
that keyword there just to get my program compiled. I know what I'm
doing, I thought. But later, when reading the code, I found it very
helpful to know that my a could be changed when invoking fun. As
always, code is read much more times than written, and I think this
little tips help better understand the code.
What do you think?
It would make template programming harder.
template TplFn(alias fn)
{
void TplFn(T...)(T t)
{
fn(t); // what if fn has normal, ref and out args?
}
}
Re: GPU/CPU roadmaps
language_fan Wrote: Tue, 11 Aug 2009 00:37:46 -0400, Jeremie Pelletier thusly wrote: I wouldn't be surprised to see major games releases built in D in a few years. It's quite optimistic to think that the toolchain will be usable and robust enough on the large scale in a few years. For instance adding the keywords immutable, const, and pure will not magically turn D into the state of the art research language in the category of pure functional languages. Yeah it's optimistic, but not unrealistic. Most of the concepts talked about in the presentation are covered on Bartosz's blog, which I've been reading with much interest in the past days, and will most likely end up in D sooner or later. From what I read of the presentation, functional programming is only a quarter of his framework concept (dealing with physics and the likes), there is still STM for game state, good old sequencial programming to talk to the hardware, and then highly parallel vector processing. For the moment libraries like OpenCL could be used to provide the vector processing, and STM only requires a software implementation, it doesn't have to be part of the language, because we don't want it everywhere (that 30% performance overhead is scary). As for the masses of libraries already available in C++, they can all be ported to D, with less code, and performing more efficiently. 3rd party middleware usually have a C API so its not a problem either. Thats the beauty of abstractions, if we abstract OpenCL now for vector processing, we can just replace this module in the future to use intel's larrabee and all the code using the interface wouldn't see the difference. So yeah, I'm optimistic, because I know its something we can start designing right away, and thinking about things like that is exactly why I love programming so much.
Re: Compile time code paths
Don Wrote:
Jeremie Pelletier wrote:
David Gileadi Wrote:
Daniel Keep wrote:
Jeremie Pelletier wrote:
If a function has both an asm and D implementations inside its body, and
the D version can be executed at compile time, but the asm one is much
faster at runtime. Is it possible to have the compiler use the D code
path at compile time (ie to fill in enums and whatnot), and have the asm
version available at runtime.
Not that I know of. There's no way to switch based on run time/compile
time. This was going to be solved, at least in part, using static
arguments, but that got dropped.
As it stands, you just have to use a suffix or prefix or something to
distinguish CTFE methods from runtime methods.
Is this a case for version(CompileTime){}?
No because it would also compile this block into the binary.
I think something like this might work:
static if (__traits(CompileTime)) {
... // ctfe code
} else {
asm {
...
}
}
Not sure what the exact syntax should be.
Good idea, I agree with the use of __traits here. The syntax looks great to me
as it is.
Re: Explicitly saying ref or out when invoking a function
Ary Borenszweig wrote: In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); When I first started using C# it really annoyed me that I had to put that keyword there just to get my program compiled. I know what I'm doing, I thought. But later, when reading the code, I found it very helpful to know that my a could be changed when invoking fun. As always, code is read much more times than written, and I think this little tips help better understand the code. What do you think? C#'s requirement is just stupid.
Re: Explicitly saying ref or out when invoking a function
Ary Borenszweig Wrote: In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); When I first started using C# it really annoyed me that I had to put that keyword there just to get my program compiled. I know what I'm doing, I thought. But later, when reading the code, I found it very helpful to know that my a could be changed when invoking fun. As always, code is read much more times than written, and I think this little tips help better understand the code. What do you think? IIRC, this is no more a case as of C# 3.0
Re: Explicitly saying ref or out when invoking a function
On Tue, Aug 11, 2009 at 11:40 AM, Ary Borenszweiga...@esperanto.org.ar wrote: In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); When I first started using C# it really annoyed me that I had to put that keyword there just to get my program compiled. I know what I'm doing, I thought. But later, when reading the code, I found it very helpful to know that my a could be changed when invoking fun. As always, code is read much more times than written, and I think this little tips help better understand the code. What do you think? I suggested it ages ago and still think it would be a nice requirement.
Re: Explicitly saying ref or out when invoking a function
Ary Borenszweig wrote: In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); What do you think? I see what you mean, however: - swap(ref a, ref b); I think that's overly verbose for a call with very descriptive function name to begin with. - Perhaps an IDE can use formatting to show you the ref parameters. - The designer of the function can always request pointers, so the caller has to explicitly pass addresses. -- Michiel Helvensteijn
Re: Void-safety (and related things)
bearophile wrote: You can't ask a single person to be able to do everything. Are you able to implement that thing? Probably I am not able. If someone here is able and willing to do it then I suggest such person to ask Walter permission to implement it. I doubt it's the direction D wants to go. Because proving correctness at compile-time requires the holy grail, and testing correctness at runtime requires extra space for each variable and extra time for each access. -- Michiel Helvensteijn
Re: Void-safety (and related things)
Michiel Helvensteijn wrote: bearophile wrote: You can't ask a single person to be able to do everything. Are you able to implement that thing? Probably I am not able. If someone here is able and willing to do it then I suggest such person to ask Walter permission to implement it. I doubt it's the direction D wants to go. Because proving correctness at compile-time requires the holy grail, and testing correctness at runtime requires extra space for each variable and extra time for each access. What do you mean by holy grail?
Re: Explicitly saying ref or out when invoking a function
On Tue, Aug 11, 2009 at 1:05 PM, Nick Sabalauskya...@a.a wrote: Ary Borenszweig a...@esperanto.org.ar wrote in message news:h5s3e9$2km...@digitalmars.com... In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); When I first started using C# it really annoyed me that I had to put that keyword there just to get my program compiled. I know what I'm doing, I thought. But later, when reading the code, I found it very helpful to know that my a could be changed when invoking fun. As always, code is read much more times than written, and I think this little tips help better understand the code. What do you think? That's something I've always liked about C# and always wanted in D. Although, what some people have said about just coloring it in an editor is not a bad point (althogh it seems like we may be starting to run out of colors...). No problem, we can resurrect BLINK! --bb
Re: Explicitly saying ref or out when invoking a function
On Tue, Aug 11, 2009 at 12:47 PM, Michiel Helvensteijnm.helvensteijn.rem...@gmail.com wrote: Ary Borenszweig wrote: In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); What do you think? I see what you mean, however: - swap(ref a, ref b); I think that's overly verbose for a call with very descriptive function name to begin with. I don't think that looks so bad. It's not like swap is used in even 1 out of 100 lines of code generally. And it's not an expression either, so it generally is written on a line all by itself. - The designer of the function can always request pointers, so the caller has to explicitly pass addresses. But pointers can be null. Refs cannot. That's one big advantage of ref args. Of course if D gets non-nullable pointers... Anyway, I generally like the idea of requiring 'ref' on the call side. But I doubt Walter will go for it. He didn't the last time it was suggested. --bb
Re: Explicitly saying ref or out when invoking a function
BCS Wrote:
It would make template programming harder.
template TplFn(alias fn)
{
void TplFn(T...)(T t)
{
fn(t); // what if fn has normal, ref and out args?
}
}
There's an intermediate solution, to make ref optional at the calling site
(as in the override case). I don't know how much this can improve the
situation.
Bye,
bearophile
Re: Void-safety (and related things)
Ary Borenszweig wrote: I doubt it's the direction D wants to go. Because proving correctness at compile-time requires the holy grail, and testing correctness at runtime requires extra space for each variable and extra time for each access. What do you mean by holy grail? You missed that discussion, did you? Basically, if you want to know at compile-time whether a variable is initialized, there are several possibilities: * Be overly conservative: Make sure every possible computational path has an assignment to the variable, otherwise give an error. This would throw out the baby with the bathwater. Many valid programs would cause an error. * Actually analyze the control flow: Make sure that exactly all reachable states have the variable initialized, otherwise give an error. Dubbed holy grail, because this sort of analysis is still some time off, and would allow some very cool correctness verification. -- Michiel Helvensteijn
Re: Explicitly saying ref or out when invoking a function
Ary Borenszweig Wrote: In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); When I first started using C# it really annoyed me that I had to put that keyword there just to get my program compiled. I know what I'm doing, I thought. But later, when reading the code, I found it very helpful to know that my a could be changed when invoking fun. As always, code is read much more times than written, and I think this little tips help better understand the code. What do you think? I think it's overkill, and it still doesn't say if the ref is const or mutable. Much like in C/C++ when you pass a pointer you dont know if its a const or mutable parameter unless you look at the function declaration. It's especially bad since if you modify the function prototype and change ref, you have all your calls to update too.
Re: Properties, opIndex, and expression rewriting.
Tue, 11 Aug 2009 03:19:42 -0400, Chad J wrote: So, Walter, how about some expression rewriting logic to solve some of the problems with properties, opIndex, and related lvalueness stuff? (I refer to the expression rewriting in the Wiki4D article on properties: http://prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semantic) Syntax can be broached later. I've also attached some D-like pseudocode of what I think such an expression rewriting algorithm would look like (propertyrewrite.d). The other file is a potential test-case. I used it to figure out what a trace of the algorithm might look like, and designed it accordingly. If it can wait a few weeks, I might try to put it into dmd and write a patch. I'll only do it if there's interest though. It would be nice if you made a patch. This way we could see for ourselves if it worked and vote for it. I've noticed an optimization which reduces number of calls to a getter. I think you shouldn't do that: you should call getter as many times as the expression suggests, and leave the rest to the optimizer.
Re: Explicitly saying ref or out when invoking a function
On Tue, Aug 11, 2009 at 4:05 PM, Nick Sabalauskya...@a.a wrote: Although, what some people have said about just coloring it in an editor is not a bad point (althogh it seems like we may be starting to run out of colors...). If your syntax highlighting is using so many colors that you're worried about running out, then your syntax highlighting is using too many colors ;) I never understood why some syntax highlighters make your code look like a goddamned rainbow threw up on it. There are so many colors that they stop meaning anything. Kate's default D highlighting scheme comes to mind as a particularly heinous offender. Do we really need different colors for 1, 0x1, 0b1, 01, and 1.0? They're all numbers. How about different highlighting for *every kind of string literal*?
Re: Properties, opIndex, and expression rewriting.
Sergey Gromov wrote: It would be nice if you made a patch. This way we could see for ourselves if it worked and vote for it. I know what you mean. I can try, but right now really isn't a good time for me to be working on this stuff. :( I can maybe handle it well in a month or two when I start looking for a job and I get my higher-priority projects finished. Right now I'm trying to help my family with some necessary home improvement/repair and also release a couple (finished but not ported) games at the moment. I've noticed an optimization which reduces number of calls to a getter. I think you shouldn't do that: you should call getter as many times as the expression suggests, and leave the rest to the optimizer. It's not so much an optimization. I removed those extra calls because it would create an asymmetry between how many times the getter is called and how many times the setter is called. I suppose it could be argued that the extra setter calls should be left in as well, and maybe that would be alright. To be honest, I'm not too entirely sure how to deal with that.
Re: Explicitly saying ref or out when invoking a function
Ary Borenszweig Wrote: In C# when you define a function that takes an out or ref parameter, when invoking that function you must also specify ref or out. For example: void fun(ref uint x, double y); uint a = 1; double b = 2; fun(ref a, b); What do you think? I agree
Re: Explicitly saying ref or out when invoking a function
Jarrett Billingsley jarrett.billings...@gmail.com wrote in message news:mailman.329.1250026310.14071.digitalmar...@puremagic.com... On Tue, Aug 11, 2009 at 4:05 PM, Nick Sabalauskya...@a.a wrote: Although, what some people have said about just coloring it in an editor is not a bad point (althogh it seems like we may be starting to run out of colors...). If your syntax highlighting is using so many colors that you're worried about running out, then your syntax highlighting is using too many colors ;) I never understood why some syntax highlighters make your code look like a goddamned rainbow threw up on it. There are so many colors that they stop meaning anything. Kate's default D highlighting scheme comes to mind as a particularly heinous offender. Do we really need different colors for 1, 0x1, 0b1, 01, and 1.0? They're all numbers. How about different highlighting for *every kind of string literal*? A different color for 01 would be nice until that abomination finally gets thrown out. But I do understand your point.
Re: Explicitly saying ref or out when invoking a function
Jeremie Pelletier jerem...@gmail.com wrote in message
news:h5sl4c$173...@digitalmars.com...
Ary Borenszweig Wrote:
It's especially bad since if you modify the function prototype and change
ref, you have all your calls to update too.
I'd consider that a benefit. If I have a function:
void foo(int x)
{
x += 2;
writefln(x);
}
and change that param to a ref, then I *absolutely* want all my calling code
to raise holy hell about it.
win32 capCreateCaptureWindow problem
i work on a win32 application. i try to access my web camera. when i use this api funtion; capCreateCaptureWindow(cam, WS_VISIBLE + WS_CHILD, 10, 10,266, 252, hWnd, 0); i get this error: Error: undefined identifier capCreateCaptureWindow my compile comman is: dmd webcam.d gdi32.lib advapi32.lib what am i doing wrong? how can i acces my web cam?
Re: win32 capCreateCaptureWindow problem
On Tue, Aug 11, 2009 at 6:10 PM, Ivan Boritskynibble...@gmx.com wrote: i work on a win32 application. i try to access my web camera. when i use this api funtion; capCreateCaptureWindow(cam, WS_VISIBLE + WS_CHILD, 10, 10,266, 252, hWnd, 0); i get this error: Error: undefined identifier capCreateCaptureWindow my compile comman is: dmd webcam.d gdi32.lib advapi32.lib what am i doing wrong? how can i acces my web cam? The Windows headers that come with Phobos are extremely incomplete. Try the WindowsApi bindings project instead: http://dsource.org/projects/bindings/wiki/WindowsApi
'static' keyword for positional array initialization
The 'static' keyword is required by dmd 2.031 for the second of these two definitions: int[2] static_0 = [ 1, 1 ]; static int[2] static_1 = [ 1:1 ]; Is this inconsistency by design? Should 'static' be required for both or neither? Ali
Is [ 0, 1, 2 ] an immutable array?
Does the expression [ 0, 1, 2 ] form an immutable array? If so, is the assignment to a[0] undefined below? Is it trying to modify an immutable element? int[] a = [ 0, 1, 2 ]; a[0] = 42; The reason for my thinking that [ 0, 1, 2] is an array is because it has the .dup property and this works too: int[] a = [ 0, 1, 2 ].dup; Thank you, Ali
ignored phobos request
Some time ago I requested something on .D, but it was ignored. I'm interested in why this is so. It was only a small request, maybe not fitting for .D but dsourse/phobos said that was the place for such things. (Maybe it was unintelligible again?) --- Could an option be added to the formatting to elide trailing zero's for %f ? That way it is possible to create an more optimal formatting for which the following holds: float f; s = format(f); float f2 = to!(float)(s); assert(f==f2); The formatting I'm trying to get can be seen here (decimal): http://www.h-schmidt.net/FloatApplet/IEEE754.html try 0.1, 0.0001, 10 1000 %g fails to format like this because it uses %f for as small as 10^-5, thus loosing precision for floats with leading zero's, like 0.0001234567 It would be even nicer to have this kind of formatting added to std.format! --- With little effort the default float format even could be lossless, wouldn't that be nice?
overloading
Why is function overloading not applied to nested functions?
[Issue 3240] std.numeric.findRoot only works with real
http://d.puremagic.com/issues/show_bug.cgi?id=3240 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Don clugd...@yahoo.com.au 2009-08-11 00:22:18 PDT --- Fixed in SVN commit 1246. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3232] std.math.approxEqual should consider maxAbsDiff when rhs==0 lhs!=0
http://d.puremagic.com/issues/show_bug.cgi?id=3232 --- Comment #1 from Lars T. Kyllingstad bugzi...@kyllingen.net 2009-08-11 00:36:02 PDT --- I just realised the two solutions I suggested are exactly equivalent. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2973] std.math.pow(int, int), etc.
http://d.puremagic.com/issues/show_bug.cgi?id=2973 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #6 from Don clugd...@yahoo.com.au 2009-08-11 04:58:06 PDT --- Casting to floating point is not a good solution b/c you lose performance and, in some cases, precision. Are you sure? Performance: Floating point multiplication is typically the same speed or faster than integer multiplication on most CPUs from the past 15 years. On most Intel CPUs, integer multiplication is actually done in the floating point unit. Precision: You'll only lose precision if the base is greater than the 1/real.epsilon. For an 80-bit real, this means precision is lost only when the result is exactly equal to ulong.max. And the only time that can happen is with pow(ulong.max, 1). (because ulong.max is divisible by 5, but not by 25). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3245] New: Easy bug fix available for disabled unit test code in std.encoding
http://d.puremagic.com/issues/show_bug.cgi?id=3245
Summary: Easy bug fix available for disabled unit test code in
std.encoding
Product: D
Version: 2.031
Platform: All
OS/Version: All
Status: NEW
Severity: trivial
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: y0uf00...@gmail.com
Bug: unittest line 55 in std.encoding was disabled by version(none)
Rationale: Re-enabling unittest at line 55 results in failure.
Fix: At line 1059 inside template EncoderInstance(CharType : char).
Current version:
dchar decodeReverseViaRead()()
{
auto c = read;
Fixed version:
dchar decodeReverseViaRead()()
{
dchar c = read;
Its obvious after failure point is pinned, even if not knowing the exact specs,
as decodeReverseViaRead must return a dchar, and variable c accumulates left
shifted bits in the loop, same as the nearby safeDecodeViaRead method. In
UTF-8,the auto c = read makes a char type only (thank you zerobugs debugger),
so high bits put in c are thrown away, and function may return character 0.
Re-enabled unittest code ran succesfully after above fix.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
