Re: GUI Library for D2+Phobos
On 01.07.2010 0:26, Trass3r wrote: Hmm getting an error from generator.exe: procedure entry point "_Z17qt_message_output9QtMsgTypePKc" not found in DLL QtCore4.dll using Qt 4.6.3 (qt-sdk-win-opensource-2010.04.exe), MinGW 4.4.1-tdm-2, CMake 2.8.2 Looks like a wrong QtCore4.dll gets loaded. Could you check which exactly? This tool http://www.dependencywalker.com/ doesn't require installation.
Re: Better tuples
Eric Poggel: >would it make sense to make struct instances and tuples the same thing?< It's a nice idea, but if all structs become tuples, and D needs to support separate compilation, then modules that define structs need to contain the compiled methods (instantiated templates) that implement all the features of Tuples. So to keep programs small I think it's better to keep structs simple, and define a Tuple with richer semantics. Bye, bearophile
Re: Better tuples
On 6/30/2010 7:13 PM, bearophile wrote:
I'd like to add five enhancement requests in Bugzilla, related to
std.typecons.Tuple. I show them here first for possible comments or critiques.
==
Title: [Better tuples] Better tuples
(In this bug report I talk about something similar to std.typecons.Tuple. A problem with the
"tuple" name: structs have a "tupleof" field, but it returns something quite
different from std.typecons.Tuple. This name clash must be addressed somehow to avoid confusion of
newbie D programmers.)
Some languages as Python show that good tuples (inhomogeneous sequences of
values of arbitrary types, in D they are statically typed) are very handy, they
help a lot in high-level coding.
Some syntactic support can make tuple usage natural, easy and widespread in D
programs written by all people, even newbies. But the lack of such syntax can
keep them a library feature used only by few programmers and makes impossible
some very useful tuples usage patterns. From my experience I think that in a
language as D that allows operator overloading built-in tuples are more useful
than built-in associative arrays (the main advantage of built-in associative
arrays are their type literals that enjoy type inference).
I have seen that std.typecons.Tuple is quite useful, but it misses some very
important features. Some features can just be added to it (see for example bug
4381 ) and maybe the apply(). But other features can't just be added, they need
some syntax and semantic support.
Some other useful things:
- More integration and usage of Tuple in druntime. For example the associative
array property AA.byItem() can yield tuple(key,value) lazily, and AA.items can
return a dynamic array of them.
- Some way to reverse the order of the items of a tuple (generating a tuple of
different type).
- "in" operator for tuples (as for arrays).
- More tuple-aware functions in Phobos, like a function to build an AA from a
range of tuple(key, value).
- Optional: Zip and other pairing ranges to yield tuple (currently for
efficiency they yield a pair of pointers. But this breaks abstraction. Using a
more common data structure has significant advantages. The compiler can
recognize the idiom and in some cases can avoid the creation of the Tuples that
Zip produce.
See the enhancement requests: bug 4381 , bug , bug , bug , bug
, bug
(This bug report will have dependencies on other six but reports.)
(I will append to bug 4381 a reference to this bug.)
==
Title: [Better tuples] Tuple unpacking
This is one of the tuple enhancement requests. See bug for an introduction.
Tuple unpacking is quite handy (the following syntax is just an syntax-idea,
other syntaxes can be used. This syntax is not valid in C, so I think this
syntax can be used in D):
auto foo() {
return tuple(10, "hello");
}
void main() {
(int n, string s) = foo();
writeln(n, " ", s);
(n, s) = foo(); // calls is again
int[] arr = [1, 2, 3];
(int a, int b, int c) = arr; // other kind of unpacking
int2[] arr2 = tuple(1, 2, 3);
(auto n2, auto s2) = foo(); // calls is again
}
This is the syntax that can be currently used:
auto foo() {
T1 alpha = computeIt1(...);
T1 alpha = computeIt2(...);
return Tuple!(T1, "alpha", T2, "beta")(alpha, beta);
//return tuple(alpha, beta); // alternative
}
void main() {
auto alpha_beta = foo();
use1(alpha_beta.alpha);
use2(alpha_beta.beta);
use1(alpha_beta.field[0]); // alternative
use2(alpha_beta.field[1]); // alternative
}
More syntax that can be currently used:
import std.stdio, std.typecons;
void main() {
int[] arr2 = [tuple(1, 2, 3).tupleof];
writeln(arr2);
}
But it prints:
1 2 3 1 2 3
Instead of:
[1, 2, 3]
Optional features, more advanced, that can be added later if they are seen
worth it. They are inspired by Python 2.x and 3.x syntax.
Nested unpacking:
auto foo() {
return tuple(10, tuple("hello", 1.5));
}
void main() {
(int i, (string s, double d)) = foo();
}
Python 3.x supports a partial tuple unpacking (here 'rest' will contain the tuple
("hello", 1.5) ):
def bar():
return (10, "hello", 1.5)
i, *rest = foo()
But I don't know if this is worth adding to D.
==
Title: [Better tuples] [] syntax support for tuples
This is one of the tuple enhancement requests. See bug for an introduction.
opIndex/opIndexAssign syntax support for tuples:
auto tup = tuple(10, 20, 30, 40);
writeln(tup[0]);
tup[1] = 5;
int y = tup[2];
tup[3]++;
Slice syntax for tuples (currently done with 'Tuple.slice'):
auto tup = tuple(10, 20, 30, 40, 50, 60);
auto part = tup[1 .. 3];
The type of tuple elements can differ, so the index must be known at
compile-time, just as with tupleof[].
A possible way
Better tuples
I'd like to add five enhancement requests in Bugzilla, related to
std.typecons.Tuple. I show them here first for possible comments or critiques.
==
Title: [Better tuples] Better tuples
(In this bug report I talk about something similar to std.typecons.Tuple. A
problem with the "tuple" name: structs have a "tupleof" field, but it returns
something quite different from std.typecons.Tuple. This name clash must be
addressed somehow to avoid confusion of newbie D programmers.)
Some languages as Python show that good tuples (inhomogeneous sequences of
values of arbitrary types, in D they are statically typed) are very handy, they
help a lot in high-level coding.
Some syntactic support can make tuple usage natural, easy and widespread in D
programs written by all people, even newbies. But the lack of such syntax can
keep them a library feature used only by few programmers and makes impossible
some very useful tuples usage patterns. From my experience I think that in a
language as D that allows operator overloading built-in tuples are more useful
than built-in associative arrays (the main advantage of built-in associative
arrays are their type literals that enjoy type inference).
I have seen that std.typecons.Tuple is quite useful, but it misses some very
important features. Some features can just be added to it (see for example bug
4381 ) and maybe the apply(). But other features can't just be added, they need
some syntax and semantic support.
Some other useful things:
- More integration and usage of Tuple in druntime. For example the associative
array property AA.byItem() can yield tuple(key,value) lazily, and AA.items can
return a dynamic array of them.
- Some way to reverse the order of the items of a tuple (generating a tuple of
different type).
- "in" operator for tuples (as for arrays).
- More tuple-aware functions in Phobos, like a function to build an AA from a
range of tuple(key, value).
- Optional: Zip and other pairing ranges to yield tuple (currently for
efficiency they yield a pair of pointers. But this breaks abstraction. Using a
more common data structure has significant advantages. The compiler can
recognize the idiom and in some cases can avoid the creation of the Tuples that
Zip produce.
See the enhancement requests: bug 4381 , bug , bug , bug , bug
, bug
(This bug report will have dependencies on other six but reports.)
(I will append to bug 4381 a reference to this bug.)
==
Title: [Better tuples] Tuple unpacking
This is one of the tuple enhancement requests. See bug for an introduction.
Tuple unpacking is quite handy (the following syntax is just an syntax-idea,
other syntaxes can be used. This syntax is not valid in C, so I think this
syntax can be used in D):
auto foo() {
return tuple(10, "hello");
}
void main() {
(int n, string s) = foo();
writeln(n, " ", s);
(n, s) = foo(); // calls is again
int[] arr = [1, 2, 3];
(int a, int b, int c) = arr; // other kind of unpacking
int2[] arr2 = tuple(1, 2, 3);
(auto n2, auto s2) = foo(); // calls is again
}
This is the syntax that can be currently used:
auto foo() {
T1 alpha = computeIt1(...);
T1 alpha = computeIt2(...);
return Tuple!(T1, "alpha", T2, "beta")(alpha, beta);
//return tuple(alpha, beta); // alternative
}
void main() {
auto alpha_beta = foo();
use1(alpha_beta.alpha);
use2(alpha_beta.beta);
use1(alpha_beta.field[0]); // alternative
use2(alpha_beta.field[1]); // alternative
}
More syntax that can be currently used:
import std.stdio, std.typecons;
void main() {
int[] arr2 = [tuple(1, 2, 3).tupleof];
writeln(arr2);
}
But it prints:
1 2 3 1 2 3
Instead of:
[1, 2, 3]
Optional features, more advanced, that can be added later if they are seen
worth it. They are inspired by Python 2.x and 3.x syntax.
Nested unpacking:
auto foo() {
return tuple(10, tuple("hello", 1.5));
}
void main() {
(int i, (string s, double d)) = foo();
}
Python 3.x supports a partial tuple unpacking (here 'rest' will contain the
tuple ("hello", 1.5) ):
def bar():
return (10, "hello", 1.5)
i, *rest = foo()
But I don't know if this is worth adding to D.
==
Title: [Better tuples] [] syntax support for tuples
This is one of the tuple enhancement requests. See bug for an introduction.
opIndex/opIndexAssign syntax support for tuples:
auto tup = tuple(10, 20, 30, 40);
writeln(tup[0]);
tup[1] = 5;
int y = tup[2];
tup[3]++;
Slice syntax for tuples (currently done with 'Tuple.slice'):
auto tup = tuple(10, 20, 30, 40, 50, 60);
auto part = tup[1 .. 3];
The type of tuple elements can differ, so the index must be known at
compile-time, just as with tupleof[].
A possible way to implement it (currently this can't be used):
alias this.t
Re: Interesting to see (for geeks)
Sean Kelly Wrote: > Sean Kelly Wrote: > > > Walter Bright Wrote: > > > > > Bane wrote: > > > > http://www.youtube.com/watch?v=fzza-ZbEY70 > > > > > > I generally do not watch anonymous youtube videos because I don't want to > > > spend > > > several minutes just to see if it is something I'd want to see. > > > > > > So, for the sake of people like me, can you add a summary of what this is > > > about? > > > > It's a mock movie trailer about .NET and Java. > > To elaborate, imagine the theme from Perfect Beauty, the family are Microsoft > diehards, and their young son discovers Java. Parallels are made to the > tribulations of a child telling his parents he's gay, and Java is made out to > be a guilty yet perfect pleasure. The trailer promises to be passably > entertaining and then goes on for too long as the creators try to throw in > too many snipes formatted as reviewer commentary. Yes, this pretty much kills all the fun watching it. Now you know why I didn't write anything describing it.
Re: GUI Library for D2+Phobos
Hmm getting an error from generator.exe: procedure entry point "_Z17qt_message_output9QtMsgTypePKc" not found in DLL QtCore4.dll using Qt 4.6.3 (qt-sdk-win-opensource-2010.04.exe), MinGW 4.4.1-tdm-2, CMake 2.8.2
Re: LDC, GDC for D2
On Wed, 30 Jun 2010 18:14:47 +, dsimcha wrote: > Now that Andrei's book is out and the D2 spec is (fairly) stable, is > there going to be any serious effort to port LDC to D2? Also, regarding > GDC, I've noticed that no D2-related checkins have happened in a long > time. > > In both cases, is there any good technical reason for the lack of focus > on D2, or is it just that D2 has stabilized very recently and given the > limited resources of these projects, D1 is considered a higher priority? The contributors so far don't have time any more or just lost interest. It's probably no big issue to give ppl svn access when they want to give it a try to work on ldc.
Re: Interesting to see (for geeks)
On Wed, 30 Jun 2010 09:44:30 -0700, Walter Bright wrote: > Bane wrote: >> http://www.youtube.com/watch?v=fzza-ZbEY70 > > I generally do not watch anonymous youtube videos because I don't want > to spend several minutes just to see if it is something I'd want to see. > > So, for the sake of people like me, can you add a summary of what this > is about? I hope you had not to endure the trololo (anti-troll) video I sneaked onto the ng some time ago.
Re: Class field inheritance
André Wagner wrote:
Ok, bad example :)
Here's a better example of what I wanted to ask:
class XA { uint x; }
class XB : XA { uint y; }
class A
{
XA j;
this(XA j) { this.j = j; }
}
class B : A
{
XB j;
this(XB j) { super(j); }
}
void main()
{
XB j = new XB();
j.x = 10;
j.y = 20;
B b = new B(j);
writefln("%d\n", b.j.x);
}
Why doesn't this work?
That would be because B.j hides A.j. A's constructor sets
B.super.j, not B.j.
If you try in your main, writeln( cast( A )( b ).j.x );, you
will see that A.j is set correctly.
--
Simen
Re: Class field inheritance
Ok, bad example :)
Here's a better example of what I wanted to ask:
class XA { uint x; }
class XB : XA { uint y; }
class A
{
XA j;
this(XA j) { this.j = j; }
}
class B : A
{
XB j;
this(XB j) { super(j); }
}
void main()
{
XB j = new XB();
j.x = 10;
j.y = 20;
B b = new B(j);
writefln("%d\n", b.j.x);
}
Why doesn't this work?
Re: LDC, GDC for D2
This shouldn't be a blocker by any stretch of the imagination. These two points weren't correlated. ldc2 is dead because no one is really working on it.
Re: Class field inheritance
Easy one: xa is null. This one used to bite me all the time too, since I was used to C++ where XA xa; works on its own. But in D, classes are always created by reference (think of them all as pointers), so you have to new them before using them. Just add an xa = new XA; to your constructor and it will work out.
Re: LDC, GDC for D2
dsimcha Wrote: > Now that Andrei's book is out and the D2 spec is (fairly) stable, is there > going to be any serious effort to port LDC to D2? Also, regarding GDC, I've > noticed that no D2-related checkins have happened in a long time. > > In both cases, is there any good technical reason for the lack of focus on D2, > or is it just that D2 has stabilized very recently and given the limited > resources of these projects, D1 is considered a higher priority? I'd say that in both cases it is the lack of interest from the contributors. Also, although D2 seems to have stabilized, many of the important problems in the language are not solved.
Class field inheritance
Hello,
I have code that has the following structure:
class XA { uint x; }
class XB : XA { uint y; }
class A
{
XA xa;
this() { xa.x = 2; }
}
class B
{
XB xa;
this() { xa.x = 3; xa.y = 4; }
}
void main() { B b = new B(); }
When I run, the statement that says "xa.x = 3" halts with
"object.Error: access violation". Why?
If I add "uint x" to XB, I get the same error. If I change the name
of "xa" in the class "B", I also get the same error.
I couldn't find anything in the documentation that explains how D
deals with fields in inherited classes. I'm using D2.
Regards,
Andr�
Re: Network I/O and streaming in D2
Sean Kelly wrote: So I suppose it's not a bad model to expose to users, since we'll eventually be 64-bit and fibers will probably be used by spawn() at some point. The 64 bit address space eliminates the stack size problems with threads. It's also why I think supporting stack chaining is a waste of time.
Re: Interesting to see (for geeks)
Sean Kelly wrote: Walter Bright Wrote: Bane wrote: http://www.youtube.com/watch?v=fzza-ZbEY70 I generally do not watch anonymous youtube videos because I don't want to spend several minutes just to see if it is something I'd want to see. So, for the sake of people like me, can you add a summary of what this is about? It's a mock movie trailer about .NET and Java. Thanks. I'd already seen it .
Re: Contract checking (Re: enforce()?)
On 30/06/10 17:45, Sean Kelly wrote: Norbert Nemec Wrote: On 28/06/10 12:59, bearophile wrote: Norbert Nemec: [...] to place code for input contract checking in the *calling* code. [...] Output contract checks, on the other hand should be compiled inside the returning routine. Is this a positive thing to do? Can this be done? (D must support separate compilation, but in many situations this is not done/necessary, so maybe in such situations it can be done). Is Eiffel doing it? if it's a good thing and it's doable then what kind of changes does it require to the compiler? These are good and pragmatic questions that you ask. The whole issue only arises when doing separate compilation of a library and an application. (I use the term "application" for any code that uses the library.) In an idea world (beware, I am switching of "pragmatic thinking mode" for a moment), I would describe the situation would as follows: Either part can be compiled in "debug" mode or in "release" mode. Debug mode in the library means that you want to debug the library code itself. Release mode in the library means that you trust the library code to be correct and switch off all internal checks. I see the choice of "release" for disabling contracts as a huge mistake in nomenclature. For libraries, I would ship a checked and unchecked build (with -release disabled and enabled), but none with -debug or -unittest set. Those are for internal testing and the user shouldn't care to turn on debug code in a library simply because he's debugging his own app. The idea of compiling the "in" contract into the application code is an interesting one, but I suspect it could be tricky. Consider an unchecked build of the library, a checked build of the app, and now taking the address of a library function. Worse, what if a library routine returns the address of another library routine? Now the application has a reference to an unchecked version of the function, even if the involved technical hurdles are surmounted (multiple entry points or the like). That's indeed an interesting aspect: Design by Contract (DbC) and function pointers. I am not sure how these concepts would merge properly at all. The contracts are part of the interface, so they should in fact be part of the function pointer type! Of course this would quickly become ridiculous. A strongly object oriented language like Eiffel can in principle do without function pointers. Instead, one can in most cases use classes with virtual functions that offer very similar functionality. A class interface comes with all the contracts, so everything is safe and sound. I really do not know how to deal with function pointers in the clean DbC paradigm. If you assign a function with input contracts to a function pointer, whoever uses the pointer does not know about the contracts. This however, breaks down the strong DbC concept and turns contracts into mere run time checks. Does this mean that D should give up the goal of proper DbC? Simply do the pragmatic thing and pick the best pieces from DbC without worrying about formal completeness? I guess so...
Re: LDC, GDC for D2
Trass3r Wrote: > > is there going to be any serious effort to port LDC to D2? > > http://d.puremagic.com/issues/show_bug.cgi?id=3155 > ldc2 progressed pretty good but is currently dead. This shouldn't be a blocker by any stretch of the imagination.
Re: LDC, GDC for D2
is there going to be any serious effort to port LDC to D2? http://d.puremagic.com/issues/show_bug.cgi?id=3155 ldc2 progressed pretty good but is currently dead. regarding GDC, I've noticed that no D2-related checkins have happened in a long time. gdc is currently at 2.015. It will eventually face the same problems like ldc with druntime. Some effort is taken to gradually upgrade to newer revisions but it needs more contributors.
Re: LDC, GDC for D2
dsimcha wrote: Now that Andrei's book is out and the D2 spec is (fairly) stable, is there going to be any serious effort to port LDC to D2? Also, regarding GDC, I've noticed that no D2-related checkins have happened in a long time. In both cases, is there any good technical reason for the lack of focus on D2, or is it just that D2 has stabilized very recently and given the limited resources of these projects, D1 is considered a higher priority? A coworker mentioned to me last night that GDC has been reloaded. This page: http://bitbucket.org/goshawk/gdc/wiki/Home is linked from http://www.digitalmars.com/d/download.html Andrei
LDC, GDC for D2
Now that Andrei's book is out and the D2 spec is (fairly) stable, is there going to be any serious effort to port LDC to D2? Also, regarding GDC, I've noticed that no D2-related checkins have happened in a long time. In both cases, is there any good technical reason for the lack of focus on D2, or is it just that D2 has stabilized very recently and given the limited resources of these projects, D1 is considered a higher priority?
Re: Network I/O and streaming in D2
On 6/30/10, Sean Kelly wrote: > I've been thinking about this and I think this is probably what the majority > of apps want anyway. It isn't scalable, but server apps are a whole 'nother > ball of wax. Blocking calls are convenient for simple apps, since you just call the read and write functions and don't worry about the packets. For servers, they are still pretty useful. You can use the select() call on unix to wait for any one of a set of connections to be ready for you, and when it is, you then call the same blocking read/write functions. Since you know ahead of time that they are ready, it doesn't actually wait. I imagine you could do the same with threads, but I've never actually tried it. Does this scale well? Honestly, I don't know. Every network server I've ever written has only had a handful of concurrent users anyway.
Re: Network I/O and streaming in D2
Andrei Alexandrescu Wrote: > Sean Kelly wrote: > > Walter Bright Wrote: > > > >> Sean Kelly wrote: > >>> Walter Bright Wrote: > >>> > Adam Ruppe wrote: > > My network thing is very simple: it opens a socket, then wraps it up > > in a File struct, via FILE*. Then, you can treat it the same way. > That's the traditional way to do it, but I'm not so sure it's the right > way for > the future. Wouldn't it be better to have an interface to it that is a > range, > rather than pretend it's a FILE* ? > >>> And in either case, if the buffer is empty a get() operation will block, > >>> correct? > >> I'm no expert in network programming, but yes. I suspect there should be a > >> settable timeout which should throw, too. > > > > I've been thinking about this and I think this is probably what the > > majority of apps want anyway. It isn't scalable, but server apps are a > > whole 'nother ball of wax. > > To obtain asynchronous operation, an app can spawn a secondary thread > using blocking I/O and passing stuff as messages. Indeed defining many > secondary threads does become a scalability issue. Yeah, this is where Java was 10 years ago. It's an easy model to program for but scales terribly, assuming you're talking about kernel threads. If the threads are replaced with fibers and context-switching takes place behind the scenes when a read or write is issued it's actually a pretty cool programming model that should scale quite well. So I suppose it's not a bad model to expose to users, since we'll eventually be 64-bit and fibers will probably be used by spawn() at some point.
Re: Network I/O and streaming in D2
Sean Kelly wrote: Walter Bright Wrote: Sean Kelly wrote: Walter Bright Wrote: Adam Ruppe wrote: My network thing is very simple: it opens a socket, then wraps it up in a File struct, via FILE*. Then, you can treat it the same way. That's the traditional way to do it, but I'm not so sure it's the right way for the future. Wouldn't it be better to have an interface to it that is a range, rather than pretend it's a FILE* ? And in either case, if the buffer is empty a get() operation will block, correct? I'm no expert in network programming, but yes. I suspect there should be a settable timeout which should throw, too. I've been thinking about this and I think this is probably what the majority of apps want anyway. It isn't scalable, but server apps are a whole 'nother ball of wax. To obtain asynchronous operation, an app can spawn a secondary thread using blocking I/O and passing stuff as messages. Indeed defining many secondary threads does become a scalability issue. Andrei
Re: Network I/O and streaming in D2
Walter Bright wrote: Adam Ruppe wrote: My network thing is very simple: it opens a socket, then wraps it up in a File struct, via FILE*. Then, you can treat it the same way. That's the traditional way to do it, but I'm not so sure it's the right way for the future. Wouldn't it be better to have an interface to it that is a range, rather than pretend it's a FILE* ? I initially also thought that a file (or socket etc.) should be a range, but then I realized that that would overload roles. It's best to have a handle/ranges architecture in which the handle (e.g. File) is responsible for opening, closing, and managing the connection, and several ranges are responsible for fetching data in various ways (by character, by chunk, by line etc.) BTW I'm virtually done implemented readf. I only need to parse floating-point numbers and strtod won't work. Walter, could you please email me your strtod implementation? Thanks. The current issue with readf (and other similar formatted read routines) is that they require a primitive peek() that looks up the current character in a stream without swallowing it. This is not a FILE* primitive, but can be simulated (slow) by using getc() and ungetc(). Fortunately on GNU's I/O libs peek() is easy to define (actually they have an internal routine by that name), and on Windows dmd uses Walter's I/O library, which again has fast peek(). Andrei
Re: Interesting to see (for geeks)
Sean Kelly Wrote: > Walter Bright Wrote: > > > Bane wrote: > > > http://www.youtube.com/watch?v=fzza-ZbEY70 > > > > I generally do not watch anonymous youtube videos because I don't want to > > spend > > several minutes just to see if it is something I'd want to see. > > > > So, for the sake of people like me, can you add a summary of what this is > > about? > > It's a mock movie trailer about .NET and Java. To elaborate, imagine the theme from Perfect Beauty, the family are Microsoft diehards, and their young son discovers Java. Parallels are made to the tribulations of a child telling his parents he's gay, and Java is made out to be a guilty yet perfect pleasure. The trailer promises to be passably entertaining and then goes on for too long as the creators try to throw in too many snipes formatted as reviewer commentary.
Re: Network I/O and streaming in D2
Robert Jacques wrote: Great, but if binary are excluded from the libcurl license, then binaries don't have any license and are unusable. That is not my understanding. The binary is not excluded from the license, it is just excluded from the attribution requirement of the license. Besides, legally I don't think he can change the interpretation of his license without changing its text. I'd recommend kindly asking him to grant you/D the right to use libcurl under the BOOST license, for legal reasons. Legally, he has every right to change and clarify his license, and since the email is after his license, it supercedes it. I believe his email to me would suffice for any dispute. IANAL. But I agree that changing the license to Boost would be better.
Re: Contract checking (Re: enforce()?)
Norbert Nemec Wrote: > On 28/06/10 12:59, bearophile wrote: > > Norbert Nemec: > >> [...] to place code for input contract checking in the *calling* code. > >> [...] > >> Output contract checks, on the other hand should be compiled inside the > >> returning routine. > > > > Is this a positive thing to do? Can this be done? (D must support separate > > compilation, but in many situations this is not done/necessary, so maybe in > > such situations it can be done). Is Eiffel doing it? if it's a good thing > > and it's doable then what kind of changes does it require to the compiler? > > These are good and pragmatic questions that you ask. > > The whole issue only arises when doing separate compilation of a library > and an application. (I use the term "application" for any code that uses > the library.) > > In an idea world (beware, I am switching of "pragmatic thinking mode" > for a moment), I would describe the situation would as follows: > > Either part can be compiled in "debug" mode or in "release" mode. Debug > mode in the library means that you want to debug the library code > itself. Release mode in the library means that you trust the library > code to be correct and switch off all internal checks. I see the choice of "release" for disabling contracts as a huge mistake in nomenclature. For libraries, I would ship a checked and unchecked build (with -release disabled and enabled), but none with -debug or -unittest set. Those are for internal testing and the user shouldn't care to turn on debug code in a library simply because he's debugging his own app. The idea of compiling the "in" contract into the application code is an interesting one, but I suspect it could be tricky. Consider an unchecked build of the library, a checked build of the app, and now taking the address of a library function. Worse, what if a library routine returns the address of another library routine? Now the application has a reference to an unchecked version of the function, even if the involved technical hurdles are surmounted (multiple entry points or the like). This seems like a nice idea but it seems too complicated. I'd rather just ship checked and unchecked builds of a library and leave it at that.
Re: Network I/O and streaming in D2
Walter Bright Wrote: > Sean Kelly wrote: > > Walter Bright Wrote: > > > >> Adam Ruppe wrote: > >>> My network thing is very simple: it opens a socket, then wraps it up > >>> in a File struct, via FILE*. Then, you can treat it the same way. > >> That's the traditional way to do it, but I'm not so sure it's the right > >> way for > >> the future. Wouldn't it be better to have an interface to it that is a > >> range, > >> rather than pretend it's a FILE* ? > > > > And in either case, if the buffer is empty a get() operation will block, > > correct? > > I'm no expert in network programming, but yes. I suspect there should be a > settable timeout which should throw, too. I've been thinking about this and I think this is probably what the majority of apps want anyway. It isn't scalable, but server apps are a whole 'nother ball of wax.
Re: Interesting to see (for geeks)
Walter Bright Wrote: > Bane wrote: > > http://www.youtube.com/watch?v=fzza-ZbEY70 > > I generally do not watch anonymous youtube videos because I don't want to > spend > several minutes just to see if it is something I'd want to see. > > So, for the sake of people like me, can you add a summary of what this is > about? It's a mock movie trailer about .NET and Java.
Re: Network I/O and streaming in D2
Sean Kelly wrote: Walter Bright Wrote: Adam Ruppe wrote: My network thing is very simple: it opens a socket, then wraps it up in a File struct, via FILE*. Then, you can treat it the same way. That's the traditional way to do it, but I'm not so sure it's the right way for the future. Wouldn't it be better to have an interface to it that is a range, rather than pretend it's a FILE* ? And in either case, if the buffer is empty a get() operation will block, correct? I'm no expert in network programming, but yes. I suspect there should be a settable timeout which should throw, too.
Re: Interesting to see (for geeks)
Bane wrote: http://www.youtube.com/watch?v=fzza-ZbEY70 I generally do not watch anonymous youtube videos because I don't want to spend several minutes just to see if it is something I'd want to see. So, for the sake of people like me, can you add a summary of what this is about?
Re: Backquotes look like regular quotes in TDPL?
strtr: > Searched for "consolas" but couldn't find the link :( Info on Consolas: http://en.wikipedia.org/wiki/Consolas Some comments on Inconsolata: http://tinyurl.com/348vw7n Bye, bearophile
Re: What exactly are the rules of governance of the development of D?
Justin Johansson wrote: Justin Johansson wrote: Walter, For the benefit of others contributing to this newsgroup and myself, would you please explain just exactly how the development of the D programing language is governed from both a legal and transparency perspective. This is just a casual question that me thinks many people would appreciate a reminder and clarification of. Regards, Justin Johansson Assuming that Walter has read this post about the governance of D by now, may it be further assumed that *no reply* is to be taken as a *swift answer*? FWIW, I for one didn't understand the question. Andrei
Re: Backquotes look like regular quotes in TDPL?
KennyTM~ wrote: On Jun 30, 10 07:12, bearophile wrote: strtr I haven't found any such problems with Consolas. (Not that I use that many different languages) I see some problems in Consolas (I see such problems even if I use it to program in D only), time ago here I have given the URL of a list of them that I have written. In my opinion Inconsolata has less problems than Consolas (despite in some situations Inconsolata looks blurred on Windows Vista and this never happens with Consolas), and Inconsolata is an open font that I can modify freely, while I have no rights to modify Consolas, so I have tried to fix them. Inconsolata author has appreciated some of my ideas and refused some other ones, but in the meantime he has not changed Inconsolata, so he's busy or he doesn't like them after all. And I think Consolas is the font Andrei has used for the code of TDPL, given that Inconsolata-g has no bold face yet, I agree with him it's the best choice, even if not perfect. Isn't it Nimbus Mono (http://en.wikipedia.org/wiki/Nimbus_Mono_L)? It's Bitstream Vera Mono with a few changes. Andrei
Re: I'd like to try D, but...
Neal Becker Wrote: > BCS wrote: > > > Hello Neal, > > > >> My main interest is building python-callable modules (which I > >> currently do with C++/boost::python). Problem is, D can't be used for > >> this, because it can't produce shared libraries (except on i386). > >> This is, as I understand it, because the D library/libraries are not > >> built as PIC. > > > > DMD will generate PIC. IIRC the issue is something to do with resolving > > all the right references in all the right places. > > > > Also: http://pyd.dsource.org/ > > > > Yes, I'm very interested in pyd. Is this still actively > developed/maintained/used? I'm not sure that Kirk is maintaining it any longer but he's still around if you want to reach him. Here's his blog: http://kirkmcdonald.blogspot.com/
Re: Backquotes look like regular quotes in TDPL?
== Quote from bearophile (bearophileh...@lycos.com)'s article > strtr > > I haven't found any such problems with Consolas. (Not that I use that many > > different languages) > I see some problems in Consolas (I see such problems even if I use it to > program in D only), time ago here I have given the URL of a list of them that I have written. Searched for "consolas" but couldn't find the link :( > In my opinion Inconsolata has less problems than Consolas (despite in some situations Inconsolata looks blurred on Windows Vista and this never happens with Consolas), and Inconsolata is an open font that I can modify freely, while I have no rights to modify Consolas, so I have tried to fix them. > Inconsolata author has appreciated some of my ideas and refused some other > ones, Probably a false dichotomy ;) > but in the meantime he has not changed Inconsolata, so he's busy or he doesn't like them after all. > And I think Consolas is the font Andrei has used for the code of TDPL, given that Inconsolata-g has no bold face yet, I agree with him it's the best choice, even if not perfect. > Bye, > bearophile
Re: Network I/O and streaming in D2
Walter Bright Wrote: > Adam Ruppe wrote: > > My network thing is very simple: it opens a socket, then wraps it up > > in a File struct, via FILE*. Then, you can treat it the same way. > > That's the traditional way to do it, but I'm not so sure it's the right way > for > the future. Wouldn't it be better to have an interface to it that is a range, > rather than pretend it's a FILE* ? And in either case, if the buffer is empty a get() operation will block, correct?
Re: Network I/O and streaming in D2
On Tue, 29 Jun 2010 22:39:03 -0400, Walter Bright wrote: Robert Jacques wrote: On Tue, 29 Jun 2010 18:26:51 -0400, Walter Bright wrote: Justin Johansson wrote: Yes, I agree that libcurl might be a choice as a backend. Is its license okay? From http://curl.haxx.se/docs/copyright.html Looks ok to me. It doesn't look okay for Phobos to me. The MIT/new BSD license is not BOOST compatible. In particular: "this permission notice appear in all copies" which includes binary copies. I emailed Daniel Stenberg, the author, about that. His reply is: = On Mon, 10 May 2010, Walter Bright wrote: > Hello, I'm Walter Bright, the lead developer on the D programming language. libcurl is the best networking library available, and we'd like to base the D runtime networking support on it. The only issue, though, is the clause in the license "provided that the above copyright notice and this permission notice appear in all copies". Does this include binaries? Or does it just apply to the source code? Thanks for your interest in libcurl and your question! The copyright notice is only for the source code, and possibly in the documentation. It is NOT for the binaries. I hope you'll find libcurl to do what you need, and I hope you'll discover that the curl-library is a fine list for help and assistance if or when you're in need! Great, but if binary are excluded from the libcurl license, then binaries don't have any license and are unusable. Besides, legally I don't think he can change the interpretation of his license without changing its text. I'd recommend kindly asking him to grant you/D the right to use libcurl under the BOOST license, for legal reasons.
Interesting to see (for geeks)
http://www.youtube.com/watch?v=fzza-ZbEY70
Re: Trying to build Tango as dynamic library on linux
On 2010-06-29 19.55, jpf wrote: On 29.06.2010 11:08, Jacob Carlborg wrote: On 2010-06-27 12:35, jpf wrote: Hi, are you still working on that? I tried to use druntime as a dynamic library on Linux, and I had exactly the same problem. (version node not found for symbol _d_th...@4) Googling showed that this problem has been discussed before: http://digitalmars.com/d/archives/digitalmars/D/libphobos_as_.so_54793.html So because of the extern(Windows) / _stdcall calling convention, dmd emits the @4 ( http://en.wikipedia.org/wiki/Name_mangling#C_name_decoration_in_Microsoft_Windows ) If I understand this http://people.redhat.com/drepper/symbol-versioning correctly, ELF uses symbol names like _d_th...@4 as n...@version. As there is no entry for version 4, linking fails. I guess mac is not affected, because Mach-O accepts _d_th...@4 as a symbol name. It seems like nothing has changed since then. http://www.dsource.org/projects/druntime/browser/trunk/src/rt/deh2.d http://www.dsource.org/projects/druntime/browser/trunk/src/rt/deh.c _d_throw is still extern(Windows) / _stdcall and i guess dmd would still emit calls to _d_th...@4 if _d_throw was changed to extern(C). Btw: Someone seems to have found a basic workaround for the name mangling problem: http://www.curoles.com/j/dso/dso.html But i guess, this should really be fixed in the compiler and druntime. I've managed to solve the linker error as shown on the last link and then got the same problem (segmentation fault) as on that site. Is this a problem with the compiler or the runtime? Same problem here. (With the dmd and druntime patches, so it's not related to the objcopy workaround) Having a short look at the relevant druntime source, I don't see how this problem could be caused by druntime. My debugging / asm skills aren't very advanced however, so I can't really tell. I guess Sean Kelly or Walter could say more on that. Maybe we should ask on the dmd-devel or the phobos mailing list (or is there a list for druntime?) That is a good idea, I don't think there is a mailing list for druntime. -- Jacob Carlborg
Re: Network I/O and streaming in D2
On 2010-06-30 04.39, Walter Bright wrote: Robert Jacques wrote: On Tue, 29 Jun 2010 18:26:51 -0400, Walter Bright wrote: Justin Johansson wrote: Yes, I agree that libcurl might be a choice as a backend. Is its license okay? From http://curl.haxx.se/docs/copyright.html Looks ok to me. It doesn't look okay for Phobos to me. The MIT/new BSD license is not BOOST compatible. In particular: "this permission notice appear in all copies" which includes binary copies. I emailed Daniel Stenberg, the author, about that. His reply is: = On Mon, 10 May 2010, Walter Bright wrote: > Hello, I'm Walter Bright, the lead developer on the D programming language. libcurl is the best networking library available, and we'd like to base the D runtime networking support on it. The only issue, though, is the clause in the license "provided that the above copyright notice and this permission notice appear in all copies". Does this include binaries? Or does it just apply to the source code? Thanks for your interest in libcurl and your question! The copyright notice is only for the source code, and possibly in the documentation. It is NOT for the binaries. I hope you'll find libcurl to do what you need, and I hope you'll discover that the curl-library is a fine list for help and assistance if or when you're in need! Then it seems that he wants the Boost license and not the MIT license. -- Jacob Carlborg
Re: Data-binding infrastructure.
On 2010-06-29 12.36, BLS wrote: On 28/06/2010 18:36, lurker wrote: Do you think Phobos could benefit by adding data-binding interfaces? The purpose is to provide the infrastructure necessary so that other libraries (GUI Toolkits, Validation, ORMs, etc) can inter-operate seamlessly. In .NET there's a whole set of interfaces for this purpose. They don't have a great design but the fact that they are standard makes possible to create an object that can be bound everywhere and performs validation everywhere (everywhere been, windows client, web application or web service). You can see all interfaces related to data-binding here: http://msdn.microsoft.com/en-us/library/41e17s4b.aspx But the more used are these three: INotifyPropertyChanged Provides an event to notify listeners that a property has changed. IDataErrorInfo Provides methods that allow validating and display corresponding GUI elements to the user. IBindingList Provides notification when a collection has changed (elements added/removed, clear, update, ...) Thanks I like the idea.. IMHO this could be done by porting and enhancing the Mono code, use Stevens dcollection lib, enhance dCollection with observable containers and you are nearly done. Due to the Mono license a phobos independent project is appropriate. my 2 cents, bjoern Why do we need to port the Mono code? This seems quite easy to implement. -- Jacob Carlborg
Re: Backquotes look like regular quotes in TDPL?
On 2010-06-29 23.57, bearophile wrote: This is how it looks at the normal size, are those backquotes good enough for you? http://tinyurl.com/398t3qu Bye, bearophile Yes, those are good enough, they actually look like backquotes :) -- Jacob Carlborg
Final switch statement
Introducing a second kind of switch in D was bad because it's a special case,
it duplicates a syntax already present, making the language more complex, etc.
(one of the bigger faults of C++ is to have two ways to do everything, one
inherited from C and one new). But given the constraints D is designed for (to
keep the same semantics of C syntax or to disallow it), it can be acceptable
even if inelegant.
I think the design of final switch needed more public discussions and more
thinking.
One problem of the 'final switch' can be solved disallowing the automatic
fall-through in both kinds of switch.
The current implementation of final switch seems to have some problems, I have
done some tests below.
This is a normal usage of final switch, repeating the enum name into each case
is not elegant, but it can be accepted:
void main() {
//static enum E1 { A, B } // wrong
enum ThisIsAnEnum { A, B }
E1 e1;
final switch(e1) {
case ThisIsAnEnum.A: break;
case ThisIsAnEnum.B: break;
}
}
It seems final switch doesn't "work" in this easy situation, and ignores the
missing case 7 (final switch is not supposed to do this, so this is not a bug,
but it can become an enhancement request):
void main() {
uint ui;
final switch(ui % 8) {
case 0: break;
case 1: break;
case 2: break;
case 3: break;
case 4: break;
case 5: break;
case 6: break;
}
}
If I have 256 values in a ubyte I can omit them all:
void main() {
ubyte u;
final switch(u) {
}
}
This shows that CaseRangeStatements are not allowed in a final switch, what's
bad in a CaseRangeStatement? It's not bug-prone:
void main() {
ubyte u;
final switch(u) {
case ubyte.min: .. case 0: break;
case 1: .. case ubyte.max: break;
}
}
// test.d(4): Error: case ranges not allowed in final switch
Strings are allowed and "ignored":
void main() {
string s;
final switch(s) {
}
}
But string enums are not allowed, I don't know why (can this become another
enhancement request):
void main() {
enum E2 : string { C="foo", D="bar" }
E2 e2;
final switch(e2) { // error: Error: 'e2' is not of integral type, it is a E2
case E2.C: break;
case E2.D: break;
}
}
I think a final switch like this is useless, because it currently can't contain
CaseRangeStatements and default and it can't contain that many cases, so maybe
it's better to disallow this:
void main() {
int i;
final switch(i) {
}
}
Bye,
bearophile
Re: I'd like to try D, but...
Neal Becker: > Yes, I'm very interested in pyd. Is this still actively > developed/maintained/used? It used to work well enough on D1. I have used it some times, Pyd was one of my motivations to learn D in the first place, because writing Python extensions in D with Pyd is for me much better than using Cython or SWIG. With just a bit of work it can probably work on the latest D1. And with some more work it can be ported to D2. As D2 gets more debugged more D1 libs will be ported to D2. Bye, bearophile
Re: I'd like to try D, but...
BCS wrote: > Hello Neal, > >> My main interest is building python-callable modules (which I >> currently do with C++/boost::python). Problem is, D can't be used for >> this, because it can't produce shared libraries (except on i386). >> This is, as I understand it, because the D library/libraries are not >> built as PIC. > > DMD will generate PIC. IIRC the issue is something to do with resolving > all the right references in all the right places. > > Also: http://pyd.dsource.org/ > Yes, I'm very interested in pyd. Is this still actively developed/maintained/used?
Re: What exactly are the rules of governance of the development of D?
Justin Johansson wrote: Walter, For the benefit of others contributing to this newsgroup and myself, would you please explain just exactly how the development of the D programing language is governed from both a legal and transparency perspective. This is just a casual question that me thinks many people would appreciate a reminder and clarification of. Regards, Justin Johansson Assuming that Walter has read this post about the governance of D by now, may it be further assumed that *no reply* is to be taken as a *swift answer*?
Re: Backquotes look like regular quotes in TDPL?
On Jun 30, 10 17:53, bearophile wrote: KennyTM~: Isn't it Nimbus Mono (http://en.wikipedia.org/wiki/Nimbus_Mono_L)? I don't know. Probably the name of the font used is written on the second cover page, or Andrei can tell you. I didn't know about Nimbus Mono, it looks a lot like Courier New. Bye, bearophile I was just checking the PDF preview chapter on this newsgroup before TDPL was published, so I can't be sure either.
Re: Backquotes look like regular quotes in TDPL?
KennyTM~: > Isn't it Nimbus Mono (http://en.wikipedia.org/wiki/Nimbus_Mono_L)? I don't know. Probably the name of the font used is written on the second cover page, or Andrei can tell you. I didn't know about Nimbus Mono, it looks a lot like Courier New. Bye, bearophile
Re: Iterating over containers of immutable objects
Jesse Phillips wrote:
Justin Johansson Wrote:
Steven Schveighoffer wrote:
while(auto bar = iter.next()) // line 37
{
...
}
Sorry that does not compile, dunno if it should I'm using
the latest D2.
I believe it needs to be written:
T bar;
while(bar = iter.next()) {
}
Yes it would be like you say if it were not for the immutable
disposition of the type T. Rereading from the start of this
thread would explain this point.
Cheers, JJ
Re: Network I/O and streaming in D2
Walter Bright wrote: Robert Jacques wrote: On Tue, 29 Jun 2010 18:26:51 -0400, Walter Bright wrote: Justin Johansson wrote: Yes, I agree that libcurl might be a choice as a backend. Is its license okay? From http://curl.haxx.se/docs/copyright.html Looks ok to me. It doesn't look okay for Phobos to me. The MIT/new BSD license is not BOOST compatible. In particular: "this permission notice appear in all copies" which includes binary copies. I emailed Daniel Stenberg, the author, about that. His reply is: = On Mon, 10 May 2010, Walter Bright wrote: > Hello, I'm Walter Bright, the lead developer on the D programming language. libcurl is the best networking library available, and we'd like to base the D runtime networking support on it. The only issue, though, is the clause in the license "provided that the above copyright notice and this permission notice appear in all copies". Does this include binaries? Or does it just apply to the source code? Thanks for your interest in libcurl and your question! The copyright notice is only for the source code, and possibly in the documentation. It is NOT for the binaries. I hope you'll find libcurl to do what you need, and I hope you'll discover that the curl-library is a fine list for help and assistance if or when you're in need! You ripper Walter!
Re: enforce()?
On 28/06/10 19:30, Andrei Alexandrescu wrote: bearophile wrote: Andrei Alexandrescu: C APIs also check their arguments. Try again, C doesn't have DbC :-) What I meant to say was that even the standard library of a language famous for its to-the-metal performance still checks parameters compulsively whenever it can. [...] Indeed, checking input arguments is essential. DbC simply means formalizing what has been done in any good libary for ages. My only intention was to make clear that checking input arguments is exactly what contracts are designed for. If the Phobos designers are worried that their input checks might be deactivated prematurely, we should fix the policy for (de/)activating the input contract checks rather than avoiding the use of input contracts they way they are intended to be used. "enforce" simply is not the right tool for this purpose: When a contract or and assertion violation is found, it is clear that there is a bug in the code. Furthermore, it is even clear which portion of the code is responsible for the bug. An assertion violation inside a library is a bug in this library. This bug may simply be a missing input contract, but this still is a bug in the library. An "enforce" violation in the library may be anything. The user has to dig into the library code to find out whether it is a library bug or a piece of incorrect input. Raising a well-defined exception gives enough information about the problem. An anonymous "enforce" on the other hand is a quick-and-dirty solution that does not help the developer very much to identify the real problem. Norbert Nemec says some good things. I think it's an area where reasonable people may disagree. Thanks bearophile, thanks Andrei as well -- I really appreciate this open exchange of ideas. Feel free to shoot back as directly as I attacked... :-)
Contract checking (Re: enforce()?)
On 28/06/10 12:59, bearophile wrote: Norbert Nemec: [...] to place code for input contract checking in the *calling* code. [...] Output contract checks, on the other hand should be compiled inside the returning routine. Is this a positive thing to do? Can this be done? (D must support separate compilation, but in many situations this is not done/necessary, so maybe in such situations it can be done). Is Eiffel doing it? if it's a good thing and it's doable then what kind of changes does it require to the compiler? These are good and pragmatic questions that you ask. The whole issue only arises when doing separate compilation of a library and an application. (I use the term "application" for any code that uses the library.) In an idea world (beware, I am switching of "pragmatic thinking mode" for a moment), I would describe the situation would as follows: Either part can be compiled in "debug" mode or in "release" mode. Debug mode in the library means that you want to debug the library code itself. Release mode in the library means that you trust the library code to be correct and switch off all internal checks. The interesting situation is when you compile the application in debug mode, using a stable library compiled in release mode. In this case, the input contracts of the library need to be checked to catch bugs in the application. Once the testing phase is finished, you want to compile the application and get rid of the contract checks. In this idealized picture, the input contracts should clearly be checked in the application code so that the application developer has control over them. Now, for the real world: Code is hardly never 100% bug free. I agree. With this argument, however, the concept of debug and release mode becomes pointless as you should never switch off the checks anyway. Assuming that you are not quite as paranoid you might still reach a point where you trust your code to switch off the checks. How about input contracts of a library? As Simen mentioned in his post, there is the issue of library authors trying to avoid blame from application authors and the other way around. Ultimately, this is exactly what contracts are for: formalize the interface as much as possible and make it machine-checkable. If an application breaks, compile it in debug mode and see whether it finds the problem. With input contracts checked in the calling code, this would automatically switch on all the relevant checks to identify bugs in the application. If the application designer still tries to blame the library, why not simply supply a library compiled in debug mode? Any violation of a contract or an assertion unquestionably signals a bug in the code. Can it be done? Certainly. The contract is part of the interface, so rather than compiling it into the DLL, it should be stored with the interface definitions and left for the application compiler to insert if requested. The code for this should not be any more involved than function inlining. Effectively, every function with contracts would be turned into a wrapper that first checks the contracts and then calls the real function in the DLL. The application compiler could then simply decide whether to inline the wrapper or simply call the function without checks. I have no idea how Eiffel does it, but I am quite certain that this solution is following the original spirit of DbC of Bertrand Meyer. Greetings, Norbert
Re: C# 4.0 dynamic vs std.variant
Adam Ruppe wrote: > If you want to play with dmdscript, I have a port to D2 here: > http://arsdnet.net/dcode/dmdscript_d2.zip Super! thanks. > You have to compile it all at once: dmd *.d, instead of incremental, > or it won't link for some reason. > > There's some hacks in that code, since I did the port using a dmd > release that had a broken in operator, and I haven't had the time to > go back and fix it since then. But, it should still work anyway. > > > The pretty.d file shows the beginnings of an opDispatch wrapper for > script objects. The biggest problem I had in making it work was > returning an object: > > dynamic a; > > a.b(); // works thanks to opDispatch calling through a lookup table > a.b.c(); // doesn't work, it complains about wrong number of args to > opDispatch, even if b is a property returning another dynamic > > I don't know if this works in the new dmds. I haven't tried for a couple > months. I think this was fixed. > > I'm pretty sure D will be able to do most of what C#4 does with bug > fixes; no new features should really be necessary. One thing it can't > do is: > > dynamic a = "hello"; // this might not compile due to opCall, but > break it into two lines and you can make it work > > string b = a; // never gonna compile, arbitrary implicit casts aren't allowed > > string b = a.coerce!string; // this is what std.variant does, works for me.
Re: Backquotes look like regular quotes in TDPL?
On Jun 30, 10 07:12, bearophile wrote: strtr I haven't found any such problems with Consolas. (Not that I use that many different languages) I see some problems in Consolas (I see such problems even if I use it to program in D only), time ago here I have given the URL of a list of them that I have written. In my opinion Inconsolata has less problems than Consolas (despite in some situations Inconsolata looks blurred on Windows Vista and this never happens with Consolas), and Inconsolata is an open font that I can modify freely, while I have no rights to modify Consolas, so I have tried to fix them. Inconsolata author has appreciated some of my ideas and refused some other ones, but in the meantime he has not changed Inconsolata, so he's busy or he doesn't like them after all. And I think Consolas is the font Andrei has used for the code of TDPL, given that Inconsolata-g has no bold face yet, I agree with him it's the best choice, even if not perfect. Isn't it Nimbus Mono (http://en.wikipedia.org/wiki/Nimbus_Mono_L)? Bye, bearophile
