Re: [ot] D users at Google
On Mon, 07 Jun 2010 22:09:31 -0700, BCS wrote: IIRC there are a few D users who work for Google (I know there is now at least one :D ) but I don't remember who. For that matter, are there other D users in the Mountain View/San Jose area? Are you the one you are referring to? I am a D user who has been working for Microsoft in Redmond for about five months. I know there is at least one other D user at Microsoft, but I suspect there are more.
Feature request: Shared receive for all waitable objects
http://d.puremagic.com/issues/show_bug.cgi?id=4365 It would be nice to be able to wait for either socket data or a cross-thread message. I've filed a bug with the request. I'm just posting here in case anyone wants to vote on the bug or in case this post will spur discussion which will cause the feature to be added sooner. Thanks, Phil Deets
Workaround for installing D1 on a directory with spaces on Windows
I really wanted to get D1 to work in a path with spaces, but it couldn't seem to find the phobos library even if I hardcoded the path in sc.ini and used quotes. I came up with a workaround that I thought I would share. I just used the short version of the path which is intended for DOS compatibility. I found a little GPL-licensed utility that converts a Windows path (which can have spaces) to the equivalent DOS path (which does not have spaces). The utility is at http://gravityfx.org/2005/07/04/dos-path/. I'm adding the next line for future searchers on a related error; so they might find this: object.d: module object cannot read file 'object.d' -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Defining some stuff for each class in turn
On Thu, 01 Oct 2009 12:53:46 -0500, Andrei Alexandrescu
wrote:
interface Comparator(T)
{
int opCmp(Comparator!T rhs);
mixin(Impl) // for each implementation Impl
{
int opCmp(Impl rhs);
override int opCmp(Comparator!T rhs)
{
return opCmp(cast(Impl) rhs);
}
}
}
I like that you can use this in interfaces too. It seems to allow for
something similar to multiple inheritance, but presumably without the
implementation difficulty.
Phil Deets
Re: SymRational, Computer Algebra
On Sun, 11 Oct 2009 12:24:57 -0500, dsimcha wrote:
I've been thinking about where a Rational struct could lead, and
realized that
the next step is to give D some capabilities for dealing with symbols.
For
example, it would be nice to have something like:
auto foo = symRational!SomeBigInt("1 / e + pi / 2 + G");
// Do a whole bunch of manipulations on foo.
writeln(foo); // Symbolic expression.
writeln(toReal(foo, constVal("G", 6e-11), constVal("pi", 3.14),
constVal("e", 2.718));
Of course, now we're starting to talk about building a basic computer
algebra
system into Phobos, or at least into some stand-alone lib. While we
clearly
don't have the manpower to do a "real" CAS, some basic CAS-like
capabilities
would be nice.
Programmers in most languages tend to use floating-point arithmetic as
their
default way of doing math. It really only makes sense to do this when
speed
is more important than precision or interpretability of the answer.
However,
it seems to get used even when this isn't the case simply because it's
what's
readily available. If D/Phobos had some built-in (very basic) CAS-like
capabilities that were as easy to use as floats, people might actually
consider using either symbolic or numerical manipulation on the relevant
tradeoffs rather than just choosing numeric because it's what's easily
available.
The problem with using a CAS's builtin language whenever you want basic
CAS-like capabilities is that it's too domain-specific. You can't easily
integrate it into a larger program that requires a full-fledged general
purpose programming language. The beauty of D is that it has so many
features
for library designers that libraries can start to look like DSLs yet
still
integrate smoothly with the general-purpose subset of D. Half the
reason why
I wrote the dstats statistics lib was to prove this concept, since
similar
issues arise in performing statistical calculations.
The question, then, becomes, how far do we go toward trying to put some
basic
CAS-like capabilities like symbolic arithmetic into Phobos? Could
things like
this really be D's killer application?
I think CAS capabilities would be much better for a third-party library
than for Phobos. The Phobos developers may not be interested in improving
it like the maintainers of a third-party library would. Also, you wouldn't
have to tie the releases of the CAS library to the Phobos releases if it
were a third-party library.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: dmd support for IDEs
On Sun, 11 Oct 2009 09:32:32 -0500, Denis Koroskin <2kor...@gmail.com> wrote: On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright wrote: In my discussions with companies about adopting D, the major barrier that comes up over and over isn't Tango vs Phobos, dmd being GPL, debugger support, libraries, bugs, etc., although those are important. It's the IDE. They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion). So, while I'm not going to be writing an IDE, I figure that dmd can help. dmd already puts out .doc and .di files. How about putting out an xml file giving all the information needed for an IDE to implement autocompletion? There'd be one .xml file generated per .d source file. The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Furthermore, an xml format would be fairly robust in the face of changes to D syntax. What do you think? I believe it won't work. It will always be slow and incomplete. Instead, I would make it easier to embed DMD into an IDE: separate DMDFE from DMDBE, fix memory leaks, remove all the static data (so that code would be re-intrable and it could work in different threads in parallel), move most of DMD code into a DLL so that an IDE could dynamically link with it and whatever it pleases with the source code. In fact, that's what I do right now. I'm writing my own D IDE in my spare time (in D, of course). I already made a lot of progress and now it's time to start implementing source code analysis. First thing I did is I made complete D bindings for C++ code. It worked out quite well but it was leaking so badly that I dropped it. Instead, I started porting DMD entirely to D (except the backend, of course), and I already got some great results. A few simple programs compile and produce byte-perfect binaries. It's still in its early stages and there is a lot of work to do, but it will be finished soon (hopefully). It could probably become a part of an official distribution, eventually. :) If anyone is interested and is willing to test and/or help, I will gladly share my code. I would like it if this went open so I could examine it and possibly contribute to it. I have wanted to do something like this, but all I have started so far is a GUI toolkit. I am new to D so I have not spent much time on it yet. It would be nice to be able to work on something more developed. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Use of first person in a book
On Fri, 09 Oct 2009 03:11:01 -0500, Andrei Alexandrescu wrote: Thanks to all who answered! I wish there was such consensus in other matters as well :o). Allow me to put forth an excerpt from TDPL without any particular reason: http://erdani.com/tdpl/excerpt.pdf Andrei Nice, but I noticed two mistakes on page 140. * "n divides p_k" => "p_k divides n" * In the paragraph starting with "Why does the iteration", the statement "If iter is greater than sqrt(n) then we can be sure iter can’t be a divisor of n" is wrong since iter could equal n (try 6 or 2 as input). The function still works since you return accum * n. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Array literals' default type
On Mon, 12 Oct 2009 09:47:34 -0500, Don wrote: (OTOH I wonder how much extant C++ code uses the comma operator. I bet there's not much of it. (But more than code than uses octal!)). Boost Assign uses the comma operator. http://www.boost.org/doc/libs/1_40_0/libs/assign/doc/index.html#operator+= However, the C++ code vector values; values += 1,2,3,4,5,6,7,8,9; could be translated to int[] values; values ~= [1,2,3,4,5,6,7,8,9]; in D so no comma operator would be needed there. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Permitted locations of a version condition
Hello, I looked over the language specification, and I could not find any
statement which says where version conditions are permitted. I assumed
that they would be permitted most places that #if would be reasonable in
C, but evidently that is not true as they do not work within enumerations.
I would definitely like the following code to work.
enum Tag
{
A, B, C,
version (5) {
D, E,
}
version (7) {
F, G,
}
// ...
}
Added enumerated values based on versions seems like something that would
be desirable. I ran into this need when converting a header file to D.
Does anyone know where version conditions are and are not allowed
currently?
Would version conditions within enumerations be a good feature to add to
D2?
If people like the idea, but the implementation is prevented due to
manpower issues, I can possibly try to implement it if you give me a
pointer on potential issues and where to look within the source code.
Re: Permitted locations of a version condition
On Thu, 29 Oct 2009 19:47:50 -0500, Ellery Newcomer wrote: And the subject has been brought up before (probably more than once). http://www.digitalmars.com/d/archives/digitalmars/D/Conditional_compilation_inside_asm_and_enum_declarations_93200.html Oops, didn't mean to repeat past discussion. This didn't show up when I searched for the issue. Thanks for the link and the code tips.
Re: Permitted locations of a version condition
On Thu, 29 Oct 2009 22:16:13 -0500, Stewart Gordon
wrote:
Phil Deets wrote:
I would definitely like the following code to work.
enum Tag
{
A, B, C,
version (5) {
D, E,
}
version (7) {
F, G,
}
// ...
}
So would I, except that it makes more sense to me to have the trailing
comma after the '}'. Commas separate, unlike semicolons, which
terminate.
I put the comma inside the version block because then there wouldn't be
duplicate commas if the version was removed. If the version number was 6
in the above example, it would evaluate to "A, B, C, D, E," with my way,
but
enum Tag
{
A, B, C,
version (5) {
D, E
},
version (7) {
F, G
},
// ...
}
would evaluate to "A, B, C, D, E, ," which has two commas in a row.
However, you could keep version blocks separated with commas if you
specialized the enum grammar specifically for version blocks, which might
be the right way to go.
Re: Permitted locations of a version condition
On Thu, 29 Oct 2009 23:26:39 -0500, Ellery Newcomer
wrote:
Phil Deets wrote:
I put the comma inside the version block because then there wouldn't be
duplicate commas if the version was removed. If the version number was 6
in the above example, it would evaluate to "A, B, C, D, E," with my way,
but
enum Tag
{
A, B, C,
version (5) {
D, E
},
version (7) {
F, G
},
// ...
}
would evaluate to "A, B, C, D, E, ," which has two commas in a row.
However, you could keep version blocks separated with commas if you
specialized the enum grammar specifically for version blocks, which
might be the right way to go.
It really doesn't matter. By the time you get around to evaluating the
version condition, you'll have thrown away all those commas anyways. All
that matters is that you can clearly distinguish the members. However,
it will be simpler to implement (and express in ebnf) if you separate
versions/members with commas. Like
enumBody -> { enumMembers }
enumMembers -> enumMember , enumMembers
enumMembers -> enumMember ,
enumMembers -> enumMember
enumMember -> Identifier
enumMember -> Identifier = AsgExp
enumMember -> ccCondition enumBody
Good point. That makes sense when I think of it that way. I was thinking
in a preprocessor mindset where the text had to make sense if the version
just disappeared like the text does with the C preprocessor.
Re: Permitted locations of a version condition
On Thu, 29 Oct 2009 19:32:56 -0500, Phil Deets wrote:
enum Tag
{
A, B, C,
version (5) {
D, E,
}
version (7) {
F, G,
}
// ...
}
Thanks to Daniel Keep on the learn newsgroup, I got a workaround working.
template Version(string symbol) {
mixin("version("~symbol~") immutable Version = true;"~
" else immutable Version = false;");
}
mixin(q"ENUM
enum Tag
{
A, B,
ENUM"~(Version!("symbol")?q"ENUM
C, D,
ENUM":"")~q"ENUM
E,
}
ENUM");
That's not pretty, but it's good enough for me; so I'll probably not do
any compiler hacking.
Re: Safety, undefined behavior, @safe, @trusted
On Thu, 05 Nov 2009 16:40:11 -0500, Adam D. Ruppe
wrote:
On Thu, Nov 05, 2009 at 10:19:27PM +0100, Ary Borenszweig wrote:
I don't want to think about
safety all the time, just let me code! If something is unsafe I'll mark
it for you, compiler, no problem, but do you think I'm just some crazy
unsafe maniac? I program safely.
This might be a problem. If safe functions can only call other safe
functions
and all functions are safe by default, unsafe becomes viral.
Let me give an example:
void main() {
doSomething();
doSomethingElse();
}
void doSomething() { does safe things }
void doSomethingElse() { oneMoreFunction(); }
void oneMoreFunction() { byte* a = cast(byte*) 0xb8000L; // unsafe!}
Now, to actually call oneMoreFunction, you have to mark it as unsafe.
Then,
since it is called in doSomethingElse, you have to mark it as unsafe.
Then,
since it is called from main, it too must be marked unsafe.
This would just get annoying.
This is bypassed by marking oneMoreFunction() as @trusted. Having an
@unsafe
is unworkable in safe by default. It is just default (safe) and marked
(trusted).
Which is going to work best for existing code? With Walter's idea, you
compile it, then fix functions piece by piece to make them safe. Since
your
other unsafe functions can still call them, the change is localized and
you
get safer with each revision.
With safe by default, you'd probably make existing code compile just by
slapping @trusted: at the top and being done with it. That's not actually
safe - you're just telling the compiler to shut up about it.
Right. Pure propagates toward callees. C++'s const member functions
propagate towards callees. I think we should use safe since it too
propagates toward callees. Having safe be default would cause an unsafe
attribute to propagate back toward callers, which seems backwards.
Re: opPow, opDollar
On Sat, 07 Nov 2009 13:37:33 -0500, Andrei Alexandrescu wrote: In order for everyone to air an informed opinion, a related question is: will loop fusion be allowed with function calls? Loop fusion currently only works with operators, and adding ^^ would allow: a[] = b[] ^^ 3; But with pow you can't do that: a[] = pow(b[], 3); Andrei If a function is marked pure, I don't see any reason why this would be a bad idea.
Re: opPow, opDollar
On Sat, 07 Nov 2009 21:31:46 -0500, Phil Deets wrote: On Sat, 07 Nov 2009 13:37:33 -0500, Andrei Alexandrescu wrote: In order for everyone to air an informed opinion, a related question is: will loop fusion be allowed with function calls? Loop fusion currently only works with operators, and adding ^^ would allow: a[] = b[] ^^ 3; But with pow you can't do that: a[] = pow(b[], 3); Andrei If a function is marked pure, I don't see any reason why this would be a bad idea. Make that pure and nothrow (and possibly safe).
Re: On Iteration
On Tue, 10 Nov 2009 05:18:59 -0500, Lutger wrote: - why is a UTF-string iterator bidirectional and why is that unexpected? I think it is wouldn't support random access since accessing the nth code point (code points are similar to characters) is not a constant time operation since different code points can be made up of different numbers of bytes. That isn't necessarily intuitive since UTF-strings are stored contiguously in memory; so you might expect them to be random-accessible.
Re: Go: A new system programing language
On Tue, 10 Nov 2009 23:09:13 -0500, Justin Johansson wrote: Knud Soerensen Wrote: Google have made a new language. See http://www.youtube.com/watch?v=rKnDgT73v8s Some of the people in the Go team include Ken Thompson and Rob Pike. As a matter of interest these people have been mentioned in a few past D NG articles. Apparently Ken Thompson designed UTF-8. Sorry if I'm stating something you already know, but Ken Thompson also was one of the main creators of UNIX.
Re: Go: A new system programing language
On Tue, 10 Nov 2009 21:21:27 -0500, Knud Soerensen <4tuu4k...@sneakemail.com> wrote: Google have made a new language. See http://www.youtube.com/watch?v=rKnDgT73v8s I watched the video. The language sounds like a cross between Smalltalk and C, but with better concurrency support. I was somewhat underwhelmed, but I do think the concurrency features are interesting.
Re: Do we really need @unsafe?
On Wed, 11 Nov 2009 06:04:16 -0500, Don wrote: Walter Bright wrote: Don wrote: Actually, I'd hope for a way of checking that @unsafe functions are called only from @trusted functions, and NOT from unmarked ones -- that's the way I'd proceed in moving a codebase over to 'safe'. That would be fairly viral. I'm concerned it would make it an impediment to use. Hopefully such functions would be really rare. It would be a strong encouragement to wrap them in an @trusted wrapper. I have a feeling people would throw on a @trusted wrapper just to save the work on propagating @unsafe attributes all through their code.
Re: How about Go's... error on unused imports?
On Thu, 12 Nov 2009 21:12:49 -0500, Leandro Lucarella wrote: I'm sorry to bring up another "How about Go's ..." topic, but I think this feature is very in sync with D and it should be really easy to implement. Go issues an error if you have an import that's never used, to avoid unnecessary dependencies. Do you see any reasons not to do that? I think it happens very often to stop using some import and never notice it. I don't think this should be an error normally. Maybe if dmd got an -analyze switch that preformed extra checks with static code analysis, this could be one of those checks. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Short list with things to finish for D2
On Sat, 21 Nov 2009 13:21:10 -0500, aarti_pl wrote: [snip] Problem with current approach is that I have to define SQL in D/Java in following way: auto statement = Select(visitcars.name).Where(And(More(visitcards.id, 100), Like(visitcards.surname, "A*"))); Please look at code in Where(). It's so awfulll! It would be so much better to write: auto statement = Select(visitcars.name).Where((visitcards.id `>` 100) `AND` (visitcards.surname `Like` "A*")); I used here syntax which you have proposed with delimiter ``. I think it is good enough solution for such purpose. [snip] Would something like expression trees (http://msdn.microsoft.com/en-us/library/bb397951.aspx) suit your needs?
Re: The great slice debate -- should slices be separated from arrays?
I'm somewhat new to D; so take everything I say with a grain of salt. It seems to me that there is a tension here between high-level and low-level. A high-level Array type might make slices be a Range. The Range would keep a reference to the Array type plus a start and end index. When the slice gets accessed, array range checking occurs to make sure the array hasn't shrunk outside of the area the Range covers. Array!(int) x = [1, 2, 3, 4, 5]; auto y = x[0..$]; x.length -= 1; y[4] // array out of bounds error Also, when Array reallocates, all the Range slices would remain valid since they call .ptr to get the pointer anyway whenever they are indexed. Maybe even appending to a Range slice would insert the elements instead of stomp. Array!(int) x = [1, 2, 3, 4, 5]; auto y = x[0..1]; y ~= [5, 6]; // x is [1, 5, 6, 2, 3, 4, 5]; The Range would tell the Array to insert the elements, and the Array would take care of informing all the slices to increase their indices if they are after the inserted data. This would require Arrays to hold weak references to all of their slices. (I know the GC doesn't support weak references, but I'm just speaking hypothetically.) I think this would be perfectly safe and would avoid all the issues presented, but the performance would suffer. This level of "fatness" would be unacceptable for many system-level applications. So maybe int[] should be low-level and perhaps even avoid appending altogether, while Array would be available as a library type. But now, we are almost back to C++ with pointers and vectors. The main difference would be D's low-level arrays store their length and can be bounds checked. Please forgive me if someone has already proposed this. I didn't go back and read all the past discussion before I posted this. I don't even know what the functionality of T[new] was; so I probably don't understand all the issues here.
Re: Dump special floating point operators
On Fri, 04 Dec 2009 11:06:31 -0500, Don wrote: Here's a table of equivalences. a!<>=b (a!=a) || (b!=b) a<>b (a==a) && (b==b) && (a!=b) a!<>b (a!=a) || (b!=b) || (a!=b) a<>=b (a==a) && (b==b) a!<=b !(a<=b) a!=b !(a>=b) a!>b !(a>b) a!>=b !(a>=b) Obviously if a or b is known at compile time, or if it is known not to be NaN, many of the <> clauses can be dropped. Isn't a!<>b equivalent to (a!=a) || (b!=b) || (a==b)? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [OT] Broken newsgroup threads in Thunderbird 3?
On Sat, 05 Dec 2009 21:21:57 -0500, Lionello Lunesu wrote: On my laptop many post that are clearly replies to an existing thread appear as new top-level posts. I use Opera 10.10 and this happens to me too.
Re: Semantics of ^^
On Tue, 08 Dec 2009 12:42:33 -0500, Bill Baxter wrote:
On Tue, Dec 8, 2009 at 2:32 AM, Don wrote:
[snip]
* If both x and y are integers, and y > 0, x^^y is equivalent to
{ auto u = x; foreach(i; 1..y) { u *= x; } return u; }
* If both x and y are integers, and y < 0, an integer divide error
occurs,
regardless of the value of x. This error is detected at compile time, if
possible.
Can you explain why you think that's necessary? Seems like going too
far towards a nanny compiler for no particularly good reason.
The fact that 2^^-1 isn't particularly useful doesn't make it
particularly error prone. No more so than integer division when the
person meant floating point division. I just find it unexpected that
a language would single out exponentiation for this kind of treatment.
I was also wondering about this. If it can't be detected at compile time,
is the result 0?
[snip]
(1) Although the following special cases could be defined...
* If x == 1, x ^^ y is 1
* If x == -1 and y is even, x^^y == 1
* If x == -1 and y is odd, x^^y == -1
... they are not sufficiently useful to justify the major increase in
complexity which they introduce.
Hmm, I'm not so sure about that. I saw examples of this being used
even in the small sampling of search results from Python and Fortran
code that I looked at. Many mathematical constructs are defined as
having a leading sign of (-1)^^n (like the sin series formula linked
above).
[snip]
I think n is always non-negative in the trig series, but some Laurent
series use negative n values. So (-1)^^n might be useful for negative n,
but you could always rewrite it as (n%2 ? -1 : 1) or ~(n&1)+1.
Re: Semantics of ^^
On Tue, 08 Dec 2009 16:44:46 -0500, Phil Deets wrote: I think n is always non-negative in the trig series, but some Laurent series use negative n values. So (-1)^^n might be useful for negative n, but you could always rewrite it as (n%2 ? -1 : 1) or ~(n&1)+1. Oops, ~(n&1)+1 doesn't work, but ~((n&1)<<1)+2 does. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: enhancing enums
On Tue, 08 Dec 2009 17:57:25 -0500, bearophile
wrote:
hehe45:
In c++ it is valid syntax to have trailing commas at the and of enum
definitions:
enum {a, b, c, };
This would be a useful addition to D too.
I think that's already possible in D1.
and in D2.
Re: Semantics of ^^
On Tue, 08 Dec 2009 22:26:10 -0500, Don wrote:
Phil Deets wrote:
On Tue, 08 Dec 2009 12:42:33 -0500, Bill Baxter
wrote:
On Tue, Dec 8, 2009 at 2:32 AM, Don wrote:
[snip]
* If both x and y are integers, and y > 0, x^^y is equivalent to
{ auto u = x; foreach(i; 1..y) { u *= x; } return u; }
* If both x and y are integers, and y < 0, an integer divide error
occurs,
regardless of the value of x. This error is detected at compile time,
if
possible.
Can you explain why you think that's necessary? Seems like going too
far towards a nanny compiler for no particularly good reason.
The fact that 2^^-1 isn't particularly useful doesn't make it
particularly error prone. No more so than integer division when the
person meant floating point division. I just find it unexpected that
a language would single out exponentiation for this kind of treatment.
I was also wondering about this. If it can't be detected at compile
time, is the result 0?
No, it's a compile-time error.
It can't be a compile-time error if it can't be detected at compile time
like I said in my question. In the code
2^^SomeFunctionFromACModuleThatReturnsInt();
the compiler can't know whether the exponent will be positive or negative.
When the code runs and a negative result is returned, will the result be
zero?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Semantics of ^^
On Wed, 09 Dec 2009 02:40:44 -0500, Phil Deets wrote:
On Tue, 08 Dec 2009 22:26:10 -0500, Don wrote:
Phil Deets wrote:
On Tue, 08 Dec 2009 12:42:33 -0500, Bill Baxter
wrote:
On Tue, Dec 8, 2009 at 2:32 AM, Don wrote:
[snip]
* If both x and y are integers, and y > 0, x^^y is equivalent to
{ auto u = x; foreach(i; 1..y) { u *= x; } return u; }
* If both x and y are integers, and y < 0, an integer divide error
occurs,
regardless of the value of x. This error is detected at compile
time, if
possible.
Can you explain why you think that's necessary? Seems like going too
far towards a nanny compiler for no particularly good reason.
The fact that 2^^-1 isn't particularly useful doesn't make it
particularly error prone. No more so than integer division when the
person meant floating point division. I just find it unexpected that
a language would single out exponentiation for this kind of treatment.
I was also wondering about this. If it can't be detected at compile
time, is the result 0?
No, it's a compile-time error.
It can't be a compile-time error if it can't be detected at compile time
like I said in my question. In the code
2^^SomeFunctionFromACModuleThatReturnsInt();
the compiler can't know whether the exponent will be positive or
negative. When the code runs and a negative result is returned, will the
result be zero?
Maybe you meant, if you can't prove it's positive, it's an error. If so, I
would suggest requiring an unsigned type.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Detecting inadvertent use of integer division
On Mon, 14 Dec 2009 04:57:26 -0500, Don wrote: In the very rare cases where the result of an integer division was actually intended to be stored in a float, an explicit cast would be required. So you'd write: double y = cast(int)(1/x); To me, double y = cast(double)(1/x); makes more sense. Why cast to int?
Re: transporting qualifier from parameter to the return value
On Wed, 16 Dec 2009 08:32:08 -0500, bearophile wrote: "auto const" I think this is the most intuitive suggestion so far.
Re: Go rant
On Mon, 21 Dec 2009 14:01:23 -0500, Walter Bright wrote: retard wrote: Agreed. Will be fixed later. Keep in mind that D is older language than Scala - now tell me what mystruct.tupleof.stringof does - where's the documentation? From the top of my head I can imagine at least 200 different cases where the D/Phobos's documentation sucks. I would appreciate it if you could list these cases, and put them in a Bugzilla issue or at least email them to me. Thanks! http://whatwg.org/html5 has a system where people can leave comments pointing out issues without even leaving the page. This lowers the bar for submitting documentation bugs. It might work for D's spec too.
Void parameter type for generic code?
I have a function which stores the return value from a D function for
access by Lua. It looks like this:
int StoreReturn(T)(lua_State* L, T ret)
{
static if (is(T==bool))
{
lua_pushboolean(L, ret?1:0);
return 1;
}
else static if (__traits(isIntegral, T))
{
lua_pushnumber(L, cast(double)ret);
return 1;
}
// etc.
else
{
// unsupported return type
static assert(0);
}
}
I would like to call it with a function like this:
int CallFunction(R, U...)(lua_State* L, R function(U) func)
{
U args;
foreach (i, arg; args)
arg = ExtractParameter!(U[i],i+1)(L);
return StoreReturn(L, func(args));
}
This works unless func returns void. I have a static if condition that
detects and handles the case where R is void, but it would be nice if I
could extend StoreReturn to include:
else static if (is(T==void))
{
return 0;
}
This doesn't work though because parameter types can't be void.
Would it be a good idea to allow void as a valid parameter type for
generic code?
Related link:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=94226
Phil Deets
Re: Concurrency architecture for D2
On Sun, 27 Dec 2009 15:32:52 -0500, Andrei Alexandrescu
wrote:
That's why I'm thinking of creating a mailing list or maybe another
group for this. Any ideas on what would be the best approach? I also
want to gauge interest from threading experts who'd like to participate.
Please advise: (a) whether you would like to participate to the design;
(b) keep discussions on the general group; (c) create a separate
newsgroup; (d) create a mailing list. The latter would have open
enrollment.
I probably wouldn't contribute much, but I'm satisfied as long as I can
view the discussion. I have learned a lot from the D newsgroups.
I would strongly prefer a newsgroup to a mailing list. I wish every
mailing list on the Internet would convert to a newsgroup.
The rest of this message is just a dump of my limited experience with
threading in case its useful for you to see the perspective of someone
without a lot of threading experience.
My only major experience with concurrency involved a program which was
split into a GUI (using C#/WPF) and a C++ DLL with three always-on threads
plus a thread from C# coming in occasionally using PInvoke. The three
threads in the C++ side were in while(true) loops which checked volatile
boolean flags for work and slept briefly when there was nothing to do.
(See below for a general idea of what the code looked like.) I didn't use
any synchronization except the volatile flags and global volatile sets of
parameters. This worked for me since only one thread handled any one piece
of functionality. So some built-in way of low overhead cross-thread
function calling would be nice. Or if there was a better way to do it, a
design that would nudge me in the right direction would be good.
Actually, after looking at the code below, I'm not convinced I got it
right since TakeData could possibly be called before thread1_buffer got
filled.
globals:
volatile bool take_data_flag = false;
volatile char* take_data_buffer = null; // constant buffer size (something
like 32KiB)
thread1:
void TakeData(char* buffer) {
take_data_buffer = buffer;
take_data_flag = true;
take_data_called = true;
}
bool take_data_called = false;
char thread1_buffer[BUFFER_SIZE];
while (true) {
if (!take_data_called) {
// Add data to thread1_buffer
if () {
TakeData(thread1_buffer);
}
} else {
if (take_data_flag == false) {
// ok to use buffer again
take_data_called = false;
}
}
sleep(50);
}
thread2:
char thread2_buffer[BUFFER_SIZE];
while (true) {
if (take_data_flag) {
// copy take_data_buffer to thread2_buffer
take_data_flag = false;
// process thread2_buffer
}
else
sleep(50);
}
Re: Concurrency architecture for D2
On Mon, 28 Dec 2009 12:46:25 -0500, Leandro Lucarella wrote: Then you will looove Gmane, because it is exactly that a NNTP gateway for almost any ML: http://www.gmane.org/ (you can add missing mailing lists) Thanks for the link. It looks awesome.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
On Wed, 31 Mar 2010 11:49:31 -0600, Nick Sabalausky wrote: Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. Crimson Editor (my preferred D text editor) has menu options to convert tabs to spaces, convert leading tabs to spaces, convert spaces to tabs, and remove trailing spaces.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
On Wed, 31 Mar 2010 21:10:22 -0600, Phil Deets wrote: On Wed, 31 Mar 2010 11:49:31 -0600, Nick Sabalausky wrote: Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. Crimson Editor (my preferred D text editor) has menu options to convert tabs to spaces, convert leading tabs to spaces, convert spaces to tabs, and remove trailing spaces. Correction: It has leading spaces to tabs, not leading tabs to spaces.
