Re: Fixing enum names in Phobos

[KennyTM~]

On Aug 1, 11 13:56, %u wrote:

How do you plan on camelCasing pure, nothrow, out, ref, etc?


pure_, nothrow_, out_, ref_

pureAttribute, nothrowAttribute, outAttribute, refAttribute

Re: Idea for @annotations

[KennyTM~]

On Aug 1, 11 13:42, %u wrote:

An idea for a potential use of annotations:

How about being able to annotate _anything_ with a template?

It would be the equivalent of Python's annotations: the template's
first parameter would be an alias to the thing being annotated, and
its return value would be the code generated for that element. Of
course, if there's no transformation being done, then it should
simply "return" the alias itself.



+1.


This would allow you to say something like:

auto memoize(alias Fn, T...)(T args) { /* memoize code here */ }

@memoize
int fib(int n) { ... }

which would be somewhat (but not completely) "equivalent" to

mixin memoize!(function int(int n) { ... });



I believe you mean

alias memoize!() fib;

your @property below won't work as a mixin.

Also, self-reference should be handled:

@memoize
ulong fib(ulong n) {
   return n < 2 ? 1 : fib(n - 2) + fib(n - 1);
//^^^ recursion^^^
}

@exportName("F/List")
class F_List {
   int content;
   F_List next;
// ^^ self-reference
}

This works in Python trivially because functions and classes are 
looked-up by name in runtime. This isn't true in D, at least if it's a 
simple alias-ing.




And more trivial things like @property would simply be
template property(alias A) { alias A property; }
with their sole effect being extra information found with
reflection.



I'd prefer to make it more explicit, e.g. use a __traits to include that 
extra information:


alias __traits(setAnnotation, X, "foo.prop", 1234) Y;
// Y is a copy or reference of X but with the extra property

enum prop = __traits(getAnnotationy, Y, "foo.prop");
// returns 1234, compile-time error if 'foo.prop' does not exist.

enum prop = __traits(getAnnotationy, Y, "foo.bar", false);
// same as above but with a default value.

static if (__traits(hasAnnotation, Y, "foo.prop"))
alias __traits(removeAnnotation, Y, "foo.prop") Z;

So, e.g. one could write

template serializable(alias F) if (is(f == struct) || ...) {
alias __traits(setAnnotation, F, "mymodule.serializable", true) 
serializable;

}

...

@serializable
struct MyObject {
   int x;
   ...
}

and the serializer can check with

auto serialize(F)(F x) if (__traits(getAnnotation, F, 
"mymodule.serializable", false)) {

   ...
}



Implementing this would obviously be difficult as I would assume,
but does it sound like a reasonable idea?


Would you mind to write a DIP? 
(http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs)


(Speaking of which, what happened to DIP11?)

Re: What library functionality would you most like to see in D?

[Marco Leise]

Am 01.08.2011, 05:31 Uhr, schrieb Jonathan M Davis :

We need to have all of the dmd and Phobos developers in triplicate. Then  
maybe we could actually get everything done that we'd like to get done...


From reading what some C++ folks think is 'forced' on them in D (making  
common things easy vs a low level structure covering all exotic use cases)  
and my experience with the RedBlackTree (it is fast but, couldn't be  
created empty as I am used to from other language libraries) I think it is  
not just about getting things done, but about brainstorming in advance.
When we use containers, what use cases do we have? Programmer A wants to  
be able to easily switch the container implementation from an array list  
to a sorted tree, B requires pure speed without the overhead of virtual  
functions and a class hierarchy. Either A or B give in, there is room for  
both in Phobos or either A or B go and (re)write the containers. I believe  
this discussion has been here already, but I wasn't reading the list at  
that time. :)
So what I want to say is, before someone starts writing the code for a  
parser generator, try to make a list of use cases. I don't say every use  
case must be covered, but it would be great, if there were 'entry points'  
for others to implement what they need. A common example is a sorted set  
that sorts by the natural ordering of elements, but can be augmented with  
a comparator function. So far we have the

- general idea of a lexer/parser
- a D source code parser
I'd be very exited to see a CTFE solution to building a parser *g*, you  
know just for the awe of it. If that works out and it turns out that it is  
actually quite fast it *could* be used to write a D parser from  
definitions. But the point that you would want to keep close to the C  
source of DMD is strong.
I wanted to write a disk cleanup tool for Linux that uses a simple special  
script language basically using list operations (like list all java  
processes -> list all files in directory x containing any processes pid ->  
protect them from deletion). The format consists keywords that can open  
new blocks that again contain other keywords, so I ended up writing parse  
functions for each block type. I'd go with a complete AST here instead of  
the linear list of tokens that has been proposed. If I wrote a syntax  
highlighter then the AST would not be of much use. So this could be two  
use cases to cover. Comments?

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

On 2011-07-31 21:06, Jim Hewes wrote:

On 7/31/2011 3:01 AM, Jacob Carlborg wrote:


I personally would like to see DWT (GUI library,
http://dsource.org/projects/dwt) in a more finished state. These are
things that need work:

* Finishing the Mac OS X port
* Update to later SWT versions
* Fixing bugs
* Port to 64bit

Any help is much appreciated. Currently DWT is a low priority for me.



I agree with this one. I'll tell you why, hopefully without getting too
long-winded. :-) I've just been a lurker here and although I like the D
language haven't really used it seriously yet.

Where I work, we use Visual Studio C++ for the main product. It's highly
unlikely that would just get switch to using D. But we also write
various small utilities and test programs that we use internally. These
are almost all written in C++ with MFC. I have never been a fan of MFC.
(Even from the beginning I preferred Borland's ObjectWindows.) But it
has some advantages. It's a common, almost standard GUI that comes with
VS and to some extent is integrated with VS. Using MFC I can produce
single-file EXEs with a GUI that can be easily passed around the company
internally. I can tell users to just grab one EXE, copy it to your
computer and run it. Very easy for people. My point here is that these
little applications are not critical and so they could be written in any
language. In my company, this would be the best way for a new language
to make inroads. I've written one or two utility apps in C# and haven't
had any complaints.


That's understandable.


For my job I work on Windows, though I try not to be an O/S fanboy and
try to treat all platforms with equal credibility. But I guess one of my
peeves about open source and Linux (which seem to go together) is that
for any target goal there are a hundred half-finished, abandoned
projects. I assume this is because people don't get paid to do it and so
once they get tired of it they move on to other more interesting things.
I can't depend on that or sell it to my colleagues. Take a look at the
GUI page on the D wiki. There are a lot of projects, but almost all of
them seem to be either in alpha or beta stage or are abandoned. Further,
in every project, each developer usually chose to use some different
array of tools that I need to download and install in my computer just
to build his project. This gets kind of annoying on Windows.


I fully agree with that and it's annoying. The wiki page could probably 
use some cleanup. About the tools, I'm working on a package manager for 
D that will ease installation of D libraries, tools and application. I 
and at least one other person is working on a build tool with the hope 
that we can all agree on one standard built tool for D.



I've recently downloaded the QtD binding to take a look because Qt seem
to be a pretty popular cross-platform library. I was able to build it
and then also build a couple of the sample projects, although I haven't
really spent time with it beyond that. It seems that not only is a Hello
World program a 1.7MB executable, but I think I would also need to
distribute the libcpp_core.dll and libcpp_gui.dll files with it for a
total of about 17MB. QtD looks like a lot of good work and I don't mean
to knock it here. I just mean to say that in contrast what would be nice
is a “standard” GUI written in D that could be statically linked and
would be not too large. I confess I have not tried the existing DWT yet,
mostly since I just didn't want to also download Tango.

Jim


DWT works with D2 (Phobos) as well. It's statically linked so the hello 
world application gets quite large. But that's because it pulls in a lot 
of the library, meaning even if you start using other parts of the 
library it won't increase the size of the executable at the same rate.


--
/Jacob Carlborg

Re: Fixing enum names in Phobos

[Jonathan M Davis]

On Monday 01 August 2011 08:26:26 Alex Rønne Petersen wrote:
> As for std.compiler.Vendor: I'm not sure if renaming these is a good
> idea. On one hand, there's consistency, but on the other hand, you'd
> probably want actual project/product/company names like that to be
> spelled correctly... That's why I just followed the pascal case
> convention in my patches.

That's a case where there's a decent argument for not camelcasing them - 
though Unknown should probably be changed to unknown. And since it's brand 
new, it wouldn't even break any code to do that. Though of course, there's 
still the issue of whether or not std.compiler should be deprecated in favor 
of just using core.rt.compiler. But regardless of where the enum ends up, the 
naming issue is still the same.

- Jonathan M Davis

Re: Fixing enum names in Phobos

[Jonathan M Davis]

On Monday 01 August 2011 15:02:54 KennyTM~ wrote:
> On Aug 1, 11 13:56, %u wrote:
> > How do you plan on camelCasing pure, nothrow, out, ref, etc?
> 
> pure_, nothrow_, out_, ref_
> 
> pureAttribute, nothrowAttribute, outAttribute, refAttribute

Yeah. Something like that. You'd have to add a prefix or a suffix to them all. 
But the fact that you can't actually just camelcase them might be a good 
argument for leaving them as-is. If we're willing to change them though, a 
simple prefix or suffix shouldn't be all that big a deal - especially if it's 
shorter rather than longer.

- Jonathan M Davis

Re: Still cannot build Phobos from git

[Jacob Carlborg]

On 2011-07-31 22:26, Nick Sabalausky wrote:

"Jacob Carlborg"  wrote in message
news:j139bn$13bj$2...@digitalmars.com...

On 2011-07-31 11:31, Nick Sabalausky wrote:


I was going to go through tango.sys.Process to use the cmdline git to
grab
it. Is there a way to just download a zip from github without going
through
git? That would be better, since it wouldn't require the user have git
installed, but I don't know of a way to do that.


You see the big "Downloads" button on every github project? Click on that,
there you can get a link to a zip file containing the sources, URL for
Phobos: https://github.com/D-Programming-Language/phobos/zipball/master



I'd already tried the "Downloads" button, but it only gives me the releases.
The, umm..."trunk"/head/master/whatever isn't listed there.


If I click the "Downloads" button I get a popup window with "Download 
source" and "Download packages". "Download source" is the current head, 
"Download packages" contains tags. BTW, I'm pretty sure it requires 
javascript to get the popup.



But, https://github.com/{user}/{repo}/zipball/master does seem to work, so
thanks, I'll use that.


Ok, good.

--
/Jacob Carlborg

Re: Fixing enum names in Phobos

[Alex Rønne Petersen]

On 01-08-2011 09:39, Jonathan M Davis wrote:

On Monday 01 August 2011 15:02:54 KennyTM~ wrote:

On Aug 1, 11 13:56, %u wrote:

How do you plan on camelCasing pure, nothrow, out, ref, etc?


pure_, nothrow_, out_, ref_

pureAttribute, nothrowAttribute, outAttribute, refAttribute


Yeah. Something like that. You'd have to add a prefix or a suffix to them all.
But the fact that you can't actually just camelcase them might be a good
argument for leaving them as-is. If we're willing to change them though, a
simple prefix or suffix shouldn't be all that big a deal - especially if it's
shorter rather than longer.

- Jonathan M Davis


I may very well be biased since I come from .NET land, but I have to 
say, camel case enum member names do seem a bit weird to me. While enum 
members could be argued to be fields, they certainly don't have those 
semantics, so maybe pascal case might not be so bad?


- Alex

Re: Idea for @annotations

[Peter Alexander]

On 1/08/11 6:42 AM, %u wrote:

An idea for a potential use of annotations:

How about being able to annotate _anything_ with a template?



What problem does this solve? Is it just syntax sugar? If so, is it 
worth complicating the language even more for this convenience?

Re: Fixing enum names in Phobos

[Jonathan M Davis]

On Monday 01 August 2011 10:00:01 Alex Rønne Petersen wrote:
> On 01-08-2011 09:39, Jonathan M Davis wrote:
> > On Monday 01 August 2011 15:02:54 KennyTM~ wrote:
> >> On Aug 1, 11 13:56, %u wrote:
> >>> How do you plan on camelCasing pure, nothrow, out, ref, etc?
> >> 
> >> pure_, nothrow_, out_, ref_
> >> 
> >> pureAttribute, nothrowAttribute, outAttribute, refAttribute
> > 
> > Yeah. Something like that. You'd have to add a prefix or a suffix to
> > them all. But the fact that you can't actually just camelcase them
> > might be a good argument for leaving them as-is. If we're willing to
> > change them though, a simple prefix or suffix shouldn't be all that big
> > a deal - especially if it's shorter rather than longer.
> > 
> > - Jonathan M Davis
> 
> I may very well be biased since I come from .NET land, but I have to
> say, camel case enum member names do seem a bit weird to me. While enum
> members could be argued to be fields, they certainly don't have those
> semantics, so maybe pascal case might not be so bad?

Camelcasing for enum values is what was decided upon, and all of the newer 
Phobos stuff follows it. It's just some of the older stuff (primarily stuff 
which 
was around in D1, I believe) which doesn't follow the correct naming 
conventions for enums. We may very well decide that it's not worth fixing these 
enums to follow the correct naming conventions for Phobos, but the correct 
naming conventions have already been decided on. Enum types are pascal cased, 
and their values are camelcased. That's not up for discussion at this point. 
What _is_ up for discussion is whether fixing these enums to follow Phobos' 
naming conventions is worth the code breakage that it will cause.

- Jonathan M Davis

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

On 2011-08-01 03:56, Jonathan M Davis wrote:

If we do a hand-written lexer of D for Phobos, it really should be a fairly
direct port of the dmd front-end. It should be _somewhat_ D-ified as
appropriate, (and the API should definitely be properly range-based and all
that), but the implementation needs to be fairly close to dmd itself so that
it's easy for someone to port changes and fixes back and forth between the two.
Otherwise, they're going to get out of sync fairly easily. If we're not going
to do a direct port, then we might as well just do the template-based lexer
generator that Andrei and others would really like to see (which we should
still do, but I think that the hand-written lexer is nowhere near as valuable
if it's not a direct port of dmd's lexer).


In the long run I hope that this won't be necessary, I'm hoping that DMD 
will use the lexer from Phobos.



Also, I see _zero_ value in making it support D1. If it's for D2's standard
library, then what's the point of it lexing D1? That just complicates the
lexer for what is essentially a legacy product. And given that the differences
between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather
complicated to try and do a direct port which covers both D1 and D2. It would
probably be easier if the two were completely separate.

As for what I've done so far, I'd have to go look. I haven't touched it in a
couple of months, I expect. There has been a lot of other stuff that I've
needed to do, and Andrei was trying to discourage such an implementation the
last time that I brought it up. So, I haven't exactly been in a rush to get it
done. I'd like to do it, but I've been rather busy.


In this case I really don't think that you should listen to Andrei.


So, if you really want to work on a potential D lexer for Phobos, that's fine,
but I really think that it needs to be a rather direct port, and that doesn't
sound like what you've been doing.

- Jonathan M Davis



--
/Jacob Carlborg

Re: What library functionality would you most like to see in D?

[Lutger Blijdestijn]

streams and network programming is most desirable, this also impacts other 
libraries. 

Another big one is async programming. Some kind of unified, higher level 
framework to deal with this could be a huge help - it's a hard problem.

It's interesting to see that in .NET a lot of new stuff concerning async 
programming is coming out, suggesting that the (many) existing patterns are 
considered inadequate. In C# 5, async operations will be a language level 
feature with the async/await keywords. There is also the reactive extensions 
library for async streams: http://msdn.microsoft.com/en-us/data/gg577609. 
Most interesting about this one is how easy it is to compose async 
operations.

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

On Monday 01 August 2011 10:12:17 Jacob Carlborg wrote:
> On 2011-08-01 03:56, Jonathan M Davis wrote:
> > If we do a hand-written lexer of D for Phobos, it really should be a
> > fairly direct port of the dmd front-end. It should be _somewhat_
> > D-ified as appropriate, (and the API should definitely be properly
> > range-based and all that), but the implementation needs to be fairly
> > close to dmd itself so that it's easy for someone to port changes and
> > fixes back and forth between the two. Otherwise, they're going to get
> > out of sync fairly easily. If we're not going to do a direct port, then
> > we might as well just do the template-based lexer generator that Andrei
> > and others would really like to see (which we should still do, but I
> > think that the hand-written lexer is nowhere near as valuable if it's
> > not a direct port of dmd's lexer).
> 
> In the long run I hope that this won't be necessary, I'm hoping that DMD
> will use the lexer from Phobos.
> 
> > Also, I see _zero_ value in making it support D1. If it's for D2's
> > standard library, then what's the point of it lexing D1? That just
> > complicates the lexer for what is essentially a legacy product. And
> > given that the differences between D1 and D2 in dmd's lexer are covered
> > with #ifdefs, it would be rather complicated to try and do a direct
> > port which covers both D1 and D2. It would probably be easier if the
> > two were completely separate.
> > 
> > As for what I've done so far, I'd have to go look. I haven't touched it
> > in a couple of months, I expect. There has been a lot of other stuff
> > that I've needed to do, and Andrei was trying to discourage such an
> > implementation the last time that I brought it up. So, I haven't
> > exactly been in a rush to get it done. I'd like to do it, but I've been
> > rather busy.
> 
> In this case I really don't think that you should listen to Andrei.

Well, when I have multiple things on my plate, and Andrei has a major 
disagreement with one, I'm less likely to focus on that one. It's also one 
which takes quite a bit of time and focus, whereas there is other stuff which I 
can do in smaller chunks of time without needing as much focus. So, I haven't 
worked on it as much. I should probably remedy that, but there's quite a lot 
that I've been trying to get done.

So, yes. I intend to do it in spite of Andrei's opinion on the matter, but 
lately I've been focusing on other stuff which needs doing.

- Jonathan M Davis

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

On 2011-08-01 04:34, Jonathan M Davis wrote:

I can tell you right now that he wants a generic, template-based lexer /
parser generator rather than a hand-written solution. He doesn't like the idea
of the hand-written solution. And I definitely think that we should have a
template-based lexer / parser generator. The question is whether it's also
worth having a hand-written port of the dmd front-end's lexer and parser to
Phobos so that we can have on official lexer and parser in Phobos which parse D
the same way that the compiler does.

- Jonathan M Davis


I think it's absolutly worth having a hand-written port of the DMD front 
end in Phobos.


--
/Jacob Carlborg

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

On 2011-08-01 04:38, Johann MacDonagh wrote:

On 7/31/2011 10:34 PM, Jonathan M Davis wrote:

I can tell you right now that he wants a generic, template-based lexer /
parser generator rather than a hand-written solution. He doesn't like
the idea
of the hand-written solution. And I definitely think that we should
have a
template-based lexer / parser generator. The question is whether it's
also
worth having a hand-written port of the dmd front-end's lexer and
parser to
Phobos so that we can have on official lexer and parser in Phobos
which parse D
the same way that the compiler does.

- Jonathan M Davis


I see. In that case, my hybrid solution doesn't solve either problem ;)

I'll keep my code in that branch and start on something new.


I think you should continue on your lexer, we need a hand-written 
lexer/parser in Phobos, preferably a port of the DMD front end.


--
/Jacob Carlborg

Re: Idea for @annotations

[Jacob Carlborg]

On 2011-08-01 07:42, %u wrote:

An idea for a potential use of annotations:

How about being able to annotate _anything_ with a template?

It would be the equivalent of Python's annotations: the template's
first parameter would be an alias to the thing being annotated, and
its return value would be the code generated for that element. Of
course, if there's no transformation being done, then it should
simply "return" the alias itself.

This would allow you to say something like:

auto memoize(alias Fn, T...)(T args) { /* memoize code here */ }

@memoize
int fib(int n) { ... }

which would be somewhat (but not completely) "equivalent" to

mixin memoize!(function int(int n) { ... });


And more trivial things like @property would simply be
template property(alias A) { alias A property; }
with their sole effect being extra information found with
reflection.


Implementing this would obviously be difficult as I would assume,
but does it sound like a reasonable idea?


I have been thinking that exact same thing. I would love to see that in 
the compiler.


--
/Jacob Carlborg

Re: Idea for @annotations

[Jacob Carlborg]

On 2011-08-01 09:00, KennyTM~ wrote:

On Aug 1, 11 13:42, %u wrote:

An idea for a potential use of annotations:

How about being able to annotate _anything_ with a template?

It would be the equivalent of Python's annotations: the template's
first parameter would be an alias to the thing being annotated, and
its return value would be the code generated for that element. Of
course, if there's no transformation being done, then it should
simply "return" the alias itself.



+1.


This would allow you to say something like:

auto memoize(alias Fn, T...)(T args) { /* memoize code here */ }

@memoize
int fib(int n) { ... }

which would be somewhat (but not completely) "equivalent" to

mixin memoize!(function int(int n) { ... });



I believe you mean

alias memoize!() fib;

your @property below won't work as a mixin.

Also, self-reference should be handled:

@memoize
ulong fib(ulong n) {
return n < 2 ? 1 : fib(n - 2) + fib(n - 1);
// ^^^ recursion^^^
}

@exportName("F/List")
class F_List {
int content;
F_List next;
// ^^ self-reference
}

This works in Python trivially because functions and classes are
looked-up by name in runtime. This isn't true in D, at least if it's a
simple alias-ing.



And more trivial things like @property would simply be
template property(alias A) { alias A property; }
with their sole effect being extra information found with
reflection.



I'd prefer to make it more explicit, e.g. use a __traits to include that
extra information:

alias __traits(setAnnotation, X, "foo.prop", 1234) Y;
// Y is a copy or reference of X but with the extra property

enum prop = __traits(getAnnotationy, Y, "foo.prop");
// returns 1234, compile-time error if 'foo.prop' does not exist.

enum prop = __traits(getAnnotationy, Y, "foo.bar", false);
// same as above but with a default value.

static if (__traits(hasAnnotation, Y, "foo.prop"))
alias __traits(removeAnnotation, Y, "foo.prop") Z;

So, e.g. one could write

template serializable(alias F) if (is(f == struct) || ...) {
alias __traits(setAnnotation, F, "mymodule.serializable", true)
serializable;
}

...

@serializable
struct MyObject {
int x;
...
}

and the serializer can check with

auto serialize(F)(F x) if (__traits(getAnnotation, F,
"mymodule.serializable", false)) {
...
}


That would be awesome.



Implementing this would obviously be difficult as I would assume,
but does it sound like a reasonable idea?


Would you mind to write a DIP?
(http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs)

(Speaking of which, what happened to DIP11?)



--
/Jacob Carlborg

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

On 2011-08-01 10:21, Jonathan M Davis wrote:

On Monday 01 August 2011 10:12:17 Jacob Carlborg wrote:

On 2011-08-01 03:56, Jonathan M Davis wrote:

If we do a hand-written lexer of D for Phobos, it really should be a
fairly direct port of the dmd front-end. It should be _somewhat_
D-ified as appropriate, (and the API should definitely be properly
range-based and all that), but the implementation needs to be fairly
close to dmd itself so that it's easy for someone to port changes and
fixes back and forth between the two. Otherwise, they're going to get
out of sync fairly easily. If we're not going to do a direct port, then
we might as well just do the template-based lexer generator that Andrei
and others would really like to see (which we should still do, but I
think that the hand-written lexer is nowhere near as valuable if it's
not a direct port of dmd's lexer).


In the long run I hope that this won't be necessary, I'm hoping that DMD
will use the lexer from Phobos.


Also, I see _zero_ value in making it support D1. If it's for D2's
standard library, then what's the point of it lexing D1? That just
complicates the lexer for what is essentially a legacy product. And
given that the differences between D1 and D2 in dmd's lexer are covered
with #ifdefs, it would be rather complicated to try and do a direct
port which covers both D1 and D2. It would probably be easier if the
two were completely separate.

As for what I've done so far, I'd have to go look. I haven't touched it
in a couple of months, I expect. There has been a lot of other stuff
that I've needed to do, and Andrei was trying to discourage such an
implementation the last time that I brought it up. So, I haven't
exactly been in a rush to get it done. I'd like to do it, but I've been
rather busy.


In this case I really don't think that you should listen to Andrei.


Well, when I have multiple things on my plate, and Andrei has a major
disagreement with one, I'm less likely to focus on that one. It's also one
which takes quite a bit of time and focus, whereas there is other stuff which I
can do in smaller chunks of time without needing as much focus. So, I haven't
worked on it as much. I should probably remedy that, but there's quite a lot
that I've been trying to get done.

So, yes. I intend to do it in spite of Andrei's opinion on the matter, but
lately I've been focusing on other stuff which needs doing.

- Jonathan M Davis


Fair enough.

--
/Jacob Carlborg

Re: Fixing enum names in Phobos

[KennyTM~]

On Aug 1, 11 16:00, Alex Rønne Petersen wrote:

On 01-08-2011 09:39, Jonathan M Davis wrote:

On Monday 01 August 2011 15:02:54 KennyTM~ wrote:

On Aug 1, 11 13:56, %u wrote:

How do you plan on camelCasing pure, nothrow, out, ref, etc?


pure_, nothrow_, out_, ref_

pureAttribute, nothrowAttribute, outAttribute, refAttribute


Yeah. Something like that. You'd have to add a prefix or a suffix to
them all.
But the fact that you can't actually just camelcase them might be a good
argument for leaving them as-is. If we're willing to change them
though, a
simple prefix or suffix shouldn't be all that big a deal - especially
if it's
shorter rather than longer.

- Jonathan M Davis


I may very well be biased since I come from .NET land, but I have to
say, camel case enum member names do seem a bit weird to me. While enum
members could be argued to be fields, they certainly don't have those
semantics, so maybe pascal case might not be so bad?

- Alex


In .NET (almost) everything is CapitalCamelCased :D

Anyway, the rule of thumb is
 - Things are CapitalCamelCased if they can create a type
 - Otherwise, they are smallLetterCamelCased

Enum members aren't types, so they shouldn't be CapitalCamelCased.

Re: What library functionality would you most like to see in D?

[Heywood Floyd]

- DBs
- Incremental GC (for real-time apps)
- Code examples!!! ..in the docs, applies to all libs, please..

add a repo to D-Programming-Language organisation

[bioinfornatics]

hi, it 's possible to add ldc2 [1] to D-Programming-Language [2] organisation ?
[1] https://github.com/bioinfornatics/ldc2
[2] https://github.com/D-Programming-Language/

Re: Fixing enum names in Phobos

[Mehrdad]

On 8/1/2011 2:15 AM, KennyTM~ wrote:

In .NET (almost) everything is CapitalCamelCased :D

lol, it's called "PascalCased". :P

+1 for PascalCasing. It solves the keyword-ness issue.

Re: Idea for @annotations

[Mehrdad]

On 8/1/2011 12:00 AM, KennyTM~ wrote:

On Aug 1, 11 13:42, %u wrote:

mixin memoize!(function int(int n) { ... });


I believe you mean

alias memoize!() fib;

Yeah, same difference. :)


Also, self-reference should be handled:

@memoize
ulong fib(ulong n) {
   return n < 2 ? 1 : fib(n - 2) + fib(n - 1);
//^^^ recursion^^^
}

@exportName("F/List")
class F_List {
   int content;
   F_List next;
// ^^ self-reference
}
Uh-oh... Houston, I think we have a problem. :\  How would you go about 
doing this, if the return type is inferred and the annotation template 
_depends_ on the return type?
You could either go on a "best-effort" basis on the compiler, or just 
assume that internal references (whether direct or indirect) assume 
un-annotated symbols. But we could have different problems that way too 
(i.e. security holes: calling the same method from different places 
producing different results, etc.) so this would need lots of thinking 
to work correctly.

Hopefully we can figure something out, though! :)

On 8/1/2011 1:05 AM, Peter Alexander wrote:

On 1/08/11 6:42 AM, %u wrote:

An idea for a potential use of annotations:

How about being able to annotate _anything_ with a template?
What problem does this solve? Is it just syntax sugar? If so, is it 
worth complicating the language even more for this convenience? 

(1) It's beautiful!
(2) It documents the fact that you're doing a transformation on 
something else
(3) It also works pretty well for non-transforming annotations (i.e. 
those that are there just for metadata) -- you could easy add static 
assertions inside the template and return the original alias, etc.
(4) We're going to have annotations sooner or later (I hope?) so this is 
just an idea on how to make them work, without introducing a new kind of 
annotation declaration (since it works with pretty much any old template).
(5) To my (VERY) limited knowledge, this could be incredibly useful 
Aspect-Oriented Programming, if I've understood the concept correctly. I 
could very well be wrong, though.



Implementing this would obviously be difficult as I would assume,
but does it sound like a reasonable idea?
Would you mind to write a DIP? 
(http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs)
I wouldn't mind, but I think we might want to get some details straight 
first. I can't think of an obvious solution to the self-reference issue, 
so we should probably figure that part out before I actually suggest 
this for inclusion, right? :)

Re: Idea for @annotations

[bearophile]

%u:

> An idea for a potential use of annotations:

In my mind the main purpose of user-defined annotations is to allow the user to 
write small (scoped) extensions to the type system.
But Python-style annotations too are useful.

Bye,
bearophile

int[3] a = [1, 2, 3]; // Why heap?

[Mehrdad]

I'm just wondering, is there a plan to fix the

|int[3] a = [1, 2, 3];
|

issue, to not make it allocate on the heap?

It kind of sucks to see people bash D for something so trivial like this. :\

Re: int[3] a = [1, 2, 3]; // Why heap?

[Don]

Mehrdad wrote:

I'm just wondering, is there a plan to fix the

|int[3] a = [1, 2, 3];
|

issue, to not make it allocate on the heap?

It kind of sucks to see people bash D for something so trivial like 
this. :\


Yes. It's bug 2356.

Re: What does C++ do better than D? - StackOverflow.com

[Steven Schveighoffer]

On Sat, 30 Jul 2011 16:25:22 -0400, Nick Sabalausky  wrote:


What does C++ do better than D?


It's better at giving you enough time during a compile to grab a sandwich
and a latte, and generally goof off with the excuse "Can't do anything  
else

right now - it's compiling".

Boo to D, for making me have to be productive!


And thinner!  bastards!

-Steve

Hiding mixin template members should be allowed.

[Timon Gehr]

I don't know since when, but hiding mixin template members was apparently
deprecated.
What about this use case? This particular instance can be resolved easily, but
what if you want to implement multiple interfaces that all want to provide
overridable default implementations using a mixin template?

If this does not work anymore, are mixin templates any good? Is there a simple
workaround I am missing?

import std.stdio;
interface Duck{
void quack();
void walk();
}
mixin template DuckImpl(){
void quack(){
writeln("quack!");
}
void walk(){
writeln("walking...");
}
}
class NormalDuck: Duck{
mixin DuckImpl;
}
class TalkyDuck: Duck{
void quack(){ // does not work anymore

writeln("quack! quack!");
}
mixin DuckImpl;
}


void main(){
Duck a=new NormalDuck;
Duck b=new TalkyDuck;
a.quack(); a.walk();
b.quack(); b.walk();
}

tt.d(20): Error: class tt.TalkyDuck use of tt.TalkyDuck.DuckImpl!().quack()
hidden by TalkyDuck is deprecated

Cheers,
-Timon

Re: Hiding mixin template members should be allowed.

[Timon Gehr]

Oh, I see, the problem is that the functions in the mixin would call the hidden
functions instead of the new ones.

I have also found the workaround:

class DefaultTalkyDuck: Duck{
mixin DuckImpl;
}
class TalkyDuck: DefaultTalkyDuck{
override void quack(){writeln("quack! quack!");}
}

Sorry for the noise.

-Timon

Re: std.path review: second update

[Lars T. Kyllingstad]

On Sun, 31 Jul 2011 12:21:46 -0700, Jonathan M Davis wrote:

> On Sunday 31 July 2011 14:24:30 Lars T. Kyllingstad wrote:
>> On Fri, 29 Jul 2011 18:06:58 +, Lars T. Kyllingstad wrote:
>> > Here's a new update based on your comments and requests.  [...]
>> 
>> You may have noticed that I did not incorporate Steve's suggestion to
>> make the directory separator(s) a template parameter.  The reason is
>> that this is the *smallest* difference between paths on the different
>> platforms.  Drive letters and UNC paths are a much bigger difference,
>> and make interoperability near impossible.
>> 
>> Therefore, I would just like to reiterate a suggestion I made on the
>> Phobos list a while ago, which was then shot down.  What if we put the
>> entire module inside a template, like this:
>> 
>> enum Platform { windows, posix }
>> enum CaseSensitive { yes, no }
>> 
>> template Path(Platform platform, CaseSensitive caseSensitive) {
>> /* Every function in the module goes inside this template,
>>and instead of
>> 
>>version (Windows) { ... }
>> 
>>and so on, we use
>> 
>>static if (platform == Platform.windows) { ... }
>> 
>>That way, if people for some reason need to deal with POSIX
>>paths on Windows, for instance, they can just write
>> 
>>Path!(Platform.posix).someFunction(myPath);
>> */
>> }
>> 
>> // Of course, we don't want to add a cumbersome prefix every time
>> // we call a function for the current platform.  By mixing in the
>> // template, std.path can be used *exactly* like now:
>> 
>> version (Windows)private enum currentPlatform =
>> Platform.windows; else version (Posix) private enum currentPlatform
>> = Platform.posix;
>> 
>> mixin Path!(currentPlatform, platformDefaultCaseSensitivity);
>> 
>> What do you think?
> 
> Honestly, it seems like overkill and overly messy. Doing something that
> drastic would have to add a lot of value IMHO, and I just don't see it.
> And honestly, even if it _did_ add a lot of value, I think that I'd want
> a cleaner solution to be found.

I don't see what's so messy or drastic about it.  For the most part, 
you'd use the module *exactly* as you do now.

Handling paths from different platforms are not an uncommon need; people 
have requested more than once that this be possible with the new 
std.path.  Zip archives and FTP clients/servers are good examples of use 
cases.

What's nice is that this doesn't have to be added now.  We can make the 
change I suggest at any later time without breaking backwards 
compatibility.

-Lars

Re: std.path review: second update

[Jonathan M Davis]

> On Sun, 31 Jul 2011 12:21:46 -0700, Jonathan M Davis wrote:
> > On Sunday 31 July 2011 14:24:30 Lars T. Kyllingstad wrote:
> >> On Fri, 29 Jul 2011 18:06:58 +, Lars T. Kyllingstad wrote:
> >> > Here's a new update based on your comments and requests. [...]
> >> 
> >> You may have noticed that I did not incorporate Steve's suggestion to
> >> make the directory separator(s) a template parameter. The reason is
> >> that this is the *smallest* difference between paths on the different
> >> platforms. Drive letters and UNC paths are a much bigger difference,
> >> and make interoperability near impossible.
> >> 
> >> Therefore, I would just like to reiterate a suggestion I made on the
> >> Phobos list a while ago, which was then shot down. What if we put the
> >> 
> >> entire module inside a template, like this:
> >> enum Platform { windows, posix }
> >> enum CaseSensitive { yes, no }
> >> 
> >> template Path(Platform platform, CaseSensitive caseSensitive) {
> >> 
> >> /* Every function in the module goes inside this template,
> >> 
> >> and instead of
> >> 
> >> version (Windows) { ... }
> >> 
> >> and so on, we use
> >> 
> >> static if (platform == Platform.windows) { ... }
> >> 
> >> That way, if people for some reason need to deal with POSIX
> >> paths on Windows, for instance, they can just write
> >> 
> >> Path!(Platform.posix).someFunction(myPath);
> >> 
> >> */
> >> 
> >> }
> >> 
> >> // Of course, we don't want to add a cumbersome prefix every time
> >> // we call a function for the current platform. By mixing in the
> >> // template, std.path can be used *exactly* like now:
> >> 
> >> version (Windows) private enum currentPlatform =
> >> Platform.windows; else version (Posix) private enum currentPlatform
> >> = Platform.posix;
> >> 
> >> mixin Path!(currentPlatform, platformDefaultCaseSensitivity);
> >> 
> >> What do you think?
> > 
> > Honestly, it seems like overkill and overly messy. Doing something that
> > drastic would have to add a lot of value IMHO, and I just don't see it.
> > And honestly, even if it _did_ add a lot of value, I think that I'd want
> > a cleaner solution to be found.
> 
> I don't see what's so messy or drastic about it. For the most part,
> you'd use the module *exactly* as you do now.
> 
> Handling paths from different platforms are not an uncommon need; people
> have requested more than once that this be possible with the new
> std.path. Zip archives and FTP clients/servers are good examples of use
> cases.
> 
> What's nice is that this doesn't have to be added now. We can make the
> change I suggest at any later time without breaking backwards
> compatibility.

It seems very messy to me from an implementation stand point. There's also the 
question about what it does to the spellchecker. If you type extensio instead 
of extension, will the spellchecker find it, or does the additional template 
obscure it? Also, can ddoc handle it? I'm not sure that a template mixin like 
that would be properly documented.

Maybe it's ultimately a good idea, but it seems to me like it stands a good 
chance of causing problems. We'd have to have a clear grasp of all of the side 
effects first.

- Jonathan M Davis

Re: std.path review: second update

[Jonathan M Davis]

> Here's a new update based on your comments and requests. Code and docs
> are in the usual place,
> 
> https://github.com/kyllingstad/phobos/blob/std-path/std/path.d
> http://www.kyllingen.net/code/std-path/phobos-prerelease/std_path.html
> 
> Here are the highlights:
> 
> * UNC paths, i.e. \\server\share\..., are now (hopefully) handled
> correctly on Windows. See the baseName(), dirName(), rootName(),
> driveName(), pathSplitter(), etc. docs for examples.
> 
> * Support for //foo/bar paths on POSIX has been removed.
> 
> * rootName() is new.
> 
> * pathSplitter() now returns a bidirectional range.
> 
> * pathCharMatch() and fcmp() have been replaced by improved functions
> filenameCharCmp() and filenameCmp(), respectively, with optional case
> sensitivity.
> 
> * joinPath() has been renamed to buildPath().
> 
> * Added a function buildNormalizedPath(), which performs normalization
> while joining the segments.
> 
> * Redefined normalize() in terms of buildNormalizedPath().
> 
> I am still unsure of the extent to which long UNC paths (i.e. \\?\...)
> should be supported, if at all. If anyone has anything to say on the
> matter, please do. :)

Well, my previous comments on function names still stand - both in terms of 
names using Ext instead of Extension and Sep instead of sep - and also with 
regards to making non-property functions verbs (e.g. absolutePath and 
relativePath).

Aside from that, wasn't it discussed that extensions should include the . in 
them in order to cover the case where a file ends in a .? Otherwise

assert(extension("file.") == extension("file"));

So, all of the stuff dealing with extensions should probably include the dot 
in the extension. It looks like both the current std.path and your std.path 
handle it by using "" for dot and null for nothing, but distinguishing between 
null and the empty string like that isn't necessarily a good idea, and your 
documentation doesn't make the distinction clear, unlike the documentation for 
the current std.path.

So, at minimum, the docs should be clearer about null vs empty when it comes 
to the extension (and there should be tests for it), but it would arguably be 
better to just include the . in the extension.

- Jonathan M Davis

Re: What library functionality would you most like to see in D?

[Paul D. Anderson]

Heywood Floyd Wrote:

> - Code examples!!! ..in the docs, applies to all libs, please..

vote++

The language and library reference docs work well for learning what's possible 
but not at how to make it happen.

TDPL is better, but it isn't really a "cookbook" either.

The good news is that anyone can contribute to a set of code examples. Adding 
these shouldn't add to the workload of the "senior" developers. In fact 
learners should probably be the main contributors because they're the ones who 
notice what's missing.

Suggest perhaps we create a page to invite contribution to code examples. There 
is already a "Tech Tips" page -- may be revive that.

Paul

Re: std.path review: second update

[Lars T. Kyllingstad]

On Mon, 01 Aug 2011 17:24:07 +, Jonathan M Davis wrote:

>> On Sun, 31 Jul 2011 12:21:46 -0700, Jonathan M Davis wrote:
>> > On Sunday 31 July 2011 14:24:30 Lars T. Kyllingstad wrote:
>> >> On Fri, 29 Jul 2011 18:06:58 +, Lars T. Kyllingstad wrote:
>> >> > Here's a new update based on your comments and requests. [...]
>> >> 
>> >> You may have noticed that I did not incorporate Steve's suggestion
>> >> to make the directory separator(s) a template parameter. The reason
>> >> is that this is the *smallest* difference between paths on the
>> >> different platforms. Drive letters and UNC paths are a much bigger
>> >> difference, and make interoperability near impossible.
>> >> 
>> >> Therefore, I would just like to reiterate a suggestion I made on the
>> >> Phobos list a while ago, which was then shot down. What if we put
>> >> the
>> >> 
>> >> entire module inside a template, like this: enum Platform { windows,
>> >> posix }
>> >> enum CaseSensitive { yes, no }
>> >> 
>> >> template Path(Platform platform, CaseSensitive caseSensitive) {
>> >> 
>> >> /* Every function in the module goes inside this template,
>> >> 
>> >> and instead of
>> >> 
>> >> version (Windows) { ... }
>> >> 
>> >> and so on, we use
>> >> 
>> >> static if (platform == Platform.windows) { ... }
>> >> 
>> >> That way, if people for some reason need to deal with POSIX paths on
>> >> Windows, for instance, they can just write
>> >> 
>> >> Path!(Platform.posix).someFunction(myPath);
>> >> 
>> >> */
>> >> 
>> >> }
>> >> 
>> >> // Of course, we don't want to add a cumbersome prefix every time //
>> >> we call a function for the current platform. By mixing in the //
>> >> template, std.path can be used *exactly* like now:
>> >> 
>> >> version (Windows) private enum currentPlatform = Platform.windows;
>> >> else version (Posix) private enum currentPlatform = Platform.posix;
>> >> 
>> >> mixin Path!(currentPlatform, platformDefaultCaseSensitivity);
>> >> 
>> >> What do you think?
>> > 
>> > Honestly, it seems like overkill and overly messy. Doing something
>> > that drastic would have to add a lot of value IMHO, and I just don't
>> > see it. And honestly, even if it _did_ add a lot of value, I think
>> > that I'd want a cleaner solution to be found.
>> 
>> I don't see what's so messy or drastic about it. For the most part,
>> you'd use the module *exactly* as you do now.
>> 
>> Handling paths from different platforms are not an uncommon need;
>> people have requested more than once that this be possible with the new
>> std.path. Zip archives and FTP clients/servers are good examples of use
>> cases.
>> 
>> What's nice is that this doesn't have to be added now. We can make the
>> change I suggest at any later time without breaking backwards
>> compatibility.
> 
> It seems very messy to me from an implementation stand point. There's
> also the question about what it does to the spellchecker. If you type
> extensio instead of extension, will the spellchecker find it, or does
> the additional template obscure it?

I don't think we should design the library around shortcomings of the 
compiler.


> Also, can ddoc handle it? I'm not
> sure that a template mixin like that would be properly documented.

The functions would be documented as members of the Path template, and 
we'd have to state in the module introduction that the template itself 
can, for the most part, be ignored unless you really need the extra 
functionality.

The fact that the docs become slightly more convoluted is, of course, an 
argument against my solution.  However, I don't think it outweighs the 
benefits.


> Maybe it's ultimately a good idea, but it seems to me like it stands a
> good chance of causing problems. We'd have to have a clear grasp of all
> of the side effects first.

Again, it doesn't have to be decided upon now.  Adding it later is a non-
breaking change.  Actually, it would probably be a bad idea to do it now, 
when there are only a few days left of the review.

-Lars

dmd installer clobbers PATH on Windows (sometimes)

[Brad Anderson]

The NSIS script used to update the environment variable (EnvVarUpdate) has
the following warning [1]:

"Warning this code will replace paths rather than append if the existing
path exceeds the maximum string length in the NSIS build you are using. Some
setup crash can also occurs."

The default maximum string length is 1024.  There is a special build of NSIS
[2] which has a larger maximum string length (8192) that would help avoid
this problem.  There is also a patch [1] for EnvVarUpdate that detects if
the PATH will be overwritten instead of appended to and tells the user to
update their PATH manually.

I've seen this issue complained about before online but
hadn't experienced it myself until recently.  It can be a rather frustrating
problem to experience as restoring your PATH isn't trivial because there is
no way (that I know of) to look at what your PATH was before it was
destroyed and the PATH is often updated by installers (as it is with dmd).

[1]
http://nsis.sourceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries#Warning
[2] http://nsis.sourceforge.net/Special_Builds

Regards,
Brad Anderson

Re: std.path review: second update

[Lars T. Kyllingstad]

On Mon, 01 Aug 2011 17:24:14 +, Jonathan M Davis wrote:

>> Here's a new update based on your comments and requests. Code and docs
>> are in the usual place,
>> [...]
> Well, my previous comments on function names still stand - both in terms
> of names using Ext instead of Extension and Sep instead of sep -

Since the feedback has been minimal since my last update, I take it 
people are more or less happy with the module's functionality now.  
(Unless they're just tired of the whole discussion, of course. ;)) 

That means it is time to let the bikeshedding begin.  Since we have been 
unable to reach a consensus in previous discussions, and there are now 
only three days left of the review, I would really like to get a good 
sample of the general opinion here.

Folks, please state your preferences in terms of function names.  I'll 
try to put personal bias aside and compose a naming scheme that is both 
internally consistent and consistent with the majority opinion.


> and also with regards to making non-property functions verbs (e.g.
> absolutePath and relativePath).

I'd be happy to change it, but I'm at loss for good alternatives.  I seem 
to remember you suggesting makeAbsolute and makeRelative, but not being 
100% happy with them yourself.  Any other suggestions?


> Aside from that, wasn't it discussed that extensions should include the
> . in them in order to cover the case where a file ends in a .? Otherwise
> 
> assert(extension("file.") == extension("file"));
> 
> So, all of the stuff dealing with extensions should probably include the
> dot in the extension. It looks like both the current std.path and your
> std.path handle it by using "" for dot and null for nothing, but
> distinguishing between null and the empty string like that isn't
> necessarily a good idea, and your documentation doesn't make the
> distinction clear, unlike the documentation for the current std.path.
> 
> So, at minimum, the docs should be clearer about null vs empty when it
> comes to the extension (and there should be tests for it), but it would
> arguably be better to just include the . in the extension.

I'm slowly coming around to the idea of including the dot.  Unless I hear 
any loud protests I will probably do so.

-Lars

Re: What does C++ do better than D? - StackOverflow.com

[Kagamin]

Walter Bright Wrote:

> Now on reddit!
> 
> http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/

C++ has a better thought out type system.
Nice joke.
http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html

D question on bioinformatics stackexchange site

[David Nadlinger]

David Simcha (and others working on bioinformatics), you might want to 
chime in on this:


http://biostar.stackexchange.com/questions/10785/what-bioinformatics-software-is-there-written-in-d

David

Re: dmd installer clobbers PATH on Windows (sometimes)

[Ary Manzana]

On 8/1/11 2:58 PM, Brad Anderson wrote:

The NSIS script used to update the environment
variable (EnvVarUpdate) has the following warning [1]:

"Warning this code will replace paths rather than append if the existing
path exceeds the maximum string length in the NSIS build you are using.
Some setup crash can also occurs."

The default maximum string length is 1024.  There is a special build of
NSIS [2] which has a larger maximum string length (8192) that would help
avoid this problem.  There is also a patch [1] for EnvVarUpdate that
detects if the PATH will be overwritten instead of appended to and tells
the user to update their PATH manually.

I've seen this issue complained about before online but
hadn't experienced it myself until recently.  It can be a rather
frustrating problem to experience as restoring your PATH isn't trivial
because there is no way (that I know of) to look at what your PATH was
before it was destroyed and the PATH is often updated by installers (as
it is with dmd).

[1]
http://nsis.sourceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries#Warning
[2] http://nsis.sourceforge.net/Special_Builds

Regards,
Brad Anderson


Hi Brad,

IIRC I wrote the installer and I knew about the problem too because some 
people started complaining about it but I didn't know of the solution 
(maybe at that moment the solution was not known). So good you found it :-)


What we can do is to copy this patched EnvVarUpdate function to the 
installer script and use it, I think it'll be much more safe than to 
just hope the system that runs the nsis script has the patched function 
or the special build.


What do you think? Could you make that change and do a pull request? (I 
don't have a Windows machine near me anymore nor a VM).

Re: dmd installer clobbers PATH on Windows (sometimes)

[Brad Anderson]

I can make a pull request. I do think we should do what we can to have the
person that rolls the release (Walter?) use the special build though. That
way nearly everyone can benefit from the convenient PATH update in the
installer.  We programmers tend to have very large PATH variables and it'd
be unfortunate if many D users received an error message whenever they
installed and were forced to update their PATH manually (although that's
clearly an improvement over the current situation).

On Mon, Aug 1, 2011 at 12:35 PM, Ary Manzana  wrote:

> On 8/1/11 2:58 PM, Brad Anderson wrote:
>
>> The NSIS script used to update the environment
>> variable (EnvVarUpdate) has the following warning [1]:
>>
>> "Warning this code will replace paths rather than append if the existing
>> path exceeds the maximum string length in the NSIS build you are using.
>> Some setup crash can also occurs."
>>
>> The default maximum string length is 1024.  There is a special build of
>> NSIS [2] which has a larger maximum string length (8192) that would help
>> avoid this problem.  There is also a patch [1] for EnvVarUpdate that
>> detects if the PATH will be overwritten instead of appended to and tells
>> the user to update their PATH manually.
>>
>> I've seen this issue complained about before online but
>> hadn't experienced it myself until recently.  It can be a rather
>> frustrating problem to experience as restoring your PATH isn't trivial
>> because there is no way (that I know of) to look at what your PATH was
>> before it was destroyed and the PATH is often updated by installers (as
>> it is with dmd).
>>
>> [1]
>> http://nsis.sourceforge.net/**Environmental_Variables:_**
>> append,_prepend,_and_remove_**entries#Warning
>> [2] 
>> http://nsis.sourceforge.net/**Special_Builds
>>
>> Regards,
>> Brad Anderson
>>
>
> Hi Brad,
>
> IIRC I wrote the installer and I knew about the problem too because some
> people started complaining about it but I didn't know of the solution (maybe
> at that moment the solution was not known). So good you found it :-)
>
> What we can do is to copy this patched EnvVarUpdate function to the
> installer script and use it, I think it'll be much more safe than to just
> hope the system that runs the nsis script has the patched function or the
> special build.
>
> What do you think? Could you make that change and do a pull request? (I
> don't have a Windows machine near me anymore nor a VM).
>

Re: What does C++ do better than D? - StackOverflow.com

[KennyTM~]

On Aug 2, 11 02:29, Kagamin wrote:

Walter Bright Wrote:


Now on reddit!

http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/


C++ has a better thought out type system.
Nice joke.
http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html


Note that D fails to catch the 2nd error (sizediff_t kMaxDiskSpace = 10 
<< 30) either.

Re: What library functionality would you most like to see in D?

[Jim Hewes]

"Jacob Carlborg"  wrote in message 
news:j15kug$1v62$1...@digitalmars.com...

On 2011-07-31 21:06, Jim Hewes wrote:


For my job I work on Windows, though I try not to be an O/S fanboy and
try to treat all platforms with equal credibility. But I guess one of my
peeves about open source and Linux (which seem to go together) is that
for any target goal there are a hundred half-finished, abandoned
projects. I assume this is because people don't get paid to do it and so
once they get tired of it they move on to other more interesting things.
I can't depend on that or sell it to my colleagues. Take a look at the
GUI page on the D wiki. There are a lot of projects, but almost all of
them seem to be either in alpha or beta stage or are abandoned. Further,
in every project, each developer usually chose to use some different
array of tools that I need to download and install in my computer just
to build his project. This gets kind of annoying on Windows.


I fully agree with that and it's annoying. The wiki page could probably 
use some cleanup. About the tools, I'm working on a package manager for D 
that will ease installation of D libraries, tools and application. I and 
at least one other person is working on a build tool with the hope that we 
can all agree on one standard built tool for D.




I didn't mean to criticize the D compiler installation, which seems to 
install pretty well on Windows. That is, after you install it you're ready 
to go without additional setup or needing to install other things. I was 
referring more to the peripheral projects and also just to open source in 
general.


If DWT is the standard GUI in the same sense that MFC is for Microsoft C++, 
then I thought it would be nice if it were included in the installer for the 
D compiler. It could be an optional feature during installation. But if you 
do choose to install it, then right after installation you should 
immediately be able to build included sample GUI code projects.


DWT works with D2 (Phobos) as well. It's statically linked so the hello 
world application gets quite large. But that's because it pulls in a lot 
of the library, meaning even if you start using other parts of the library 
it won't increase the size of the executable at the same rate.



Yeah, the main GUI library page on the wiki says that it works with Phobos, 
but the Windows installation guide says to download Tango. So I wasn't sure 
it was really updated to support Phobos. Thanks, I will try to check it out 
next weekend.


Jim 

Re: dmd installer clobbers PATH on Windows (sometimes)

[Brad Anderson]

On Mon, Aug 1, 2011 at 12:54 PM, Brad Anderson  wrote:

> I can make a pull request. I do think we should do what we can to have the
> person that rolls the release (Walter?) use the special build though. That
> way nearly everyone can benefit from the convenient PATH update in the
> installer.  We programmers tend to have very large PATH variables and it'd
> be unfortunate if many D users received an error message whenever they
> installed and were forced to update their PATH manually (although that's
> clearly an improvement over the current situation).
>

Pull request made.  I have not tested it as I'm not familiar with the dmd
build process and don't have time at the moment to figure it out. I can test
some other day if necessary.


>
>

> On Mon, Aug 1, 2011 at 12:35 PM, Ary Manzana  wrote:
>
>> On 8/1/11 2:58 PM, Brad Anderson wrote:
>>
>>> The NSIS script used to update the environment
>>> variable (EnvVarUpdate) has the following warning [1]:
>>>
>>> "Warning this code will replace paths rather than append if the existing
>>> path exceeds the maximum string length in the NSIS build you are using.
>>> Some setup crash can also occurs."
>>>
>>> The default maximum string length is 1024.  There is a special build of
>>> NSIS [2] which has a larger maximum string length (8192) that would help
>>> avoid this problem.  There is also a patch [1] for EnvVarUpdate that
>>> detects if the PATH will be overwritten instead of appended to and tells
>>> the user to update their PATH manually.
>>>
>>> I've seen this issue complained about before online but
>>> hadn't experienced it myself until recently.  It can be a rather
>>> frustrating problem to experience as restoring your PATH isn't trivial
>>> because there is no way (that I know of) to look at what your PATH was
>>> before it was destroyed and the PATH is often updated by installers (as
>>> it is with dmd).
>>>
>>> [1]
>>> http://nsis.sourceforge.net/**Environmental_Variables:_**
>>> append,_prepend,_and_remove_**entries#Warning
>>> [2] 
>>> http://nsis.sourceforge.net/**Special_Builds
>>>
>>> Regards,
>>> Brad Anderson
>>>
>>
>> Hi Brad,
>>
>> IIRC I wrote the installer and I knew about the problem too because some
>> people started complaining about it but I didn't know of the solution (maybe
>> at that moment the solution was not known). So good you found it :-)
>>
>> What we can do is to copy this patched EnvVarUpdate function to the
>> installer script and use it, I think it'll be much more safe than to just
>> hope the system that runs the nsis script has the patched function or the
>> special build.
>>
>> What do you think? Could you make that change and do a pull request? (I
>> don't have a Windows machine near me anymore nor a VM).
>>
>
>

Re: What does C++ do better than D? - StackOverflow.com

[bearophile]

Kagamin:

> C++ has a better thought out type system.
> Nice joke.
> http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html

C++ compiled with Clang *is* better, because D doesn't catch this bug:
int kMaxDiskSpace1 = 10 << 30;

This is somewhat worse, because it gives even more false security:
long kMaxDiskSpace2 = 10 << 30;

I'll never agree that D is doing well enough here.

Bye,
bearophile

Re: std.path review: second update

[torhu]

On 01.08.2011 20:06, Lars T. Kyllingstad wrote:

On Mon, 01 Aug 2011 17:24:14 +, Jonathan M Davis wrote:


 Here's a new update based on your comments and requests. Code and docs
 are in the usual place,
 [...]

 Well, my previous comments on function names still stand - both in terms
 of names using Ext instead of Extension and Sep instead of sep -


Since the feedback has been minimal since my last update, I take it
people are more or less happy with the module's functionality now.
(Unless they're just tired of the whole discussion, of course. ;))

That means it is time to let the bikeshedding begin.  Since we have been
unable to reach a consensus in previous discussions, and there are now
only three days left of the review, I would really like to get a good
sample of the general opinion here.

Folks, please state your preferences in terms of function names.  I'll
try to put personal bias aside and compose a naming scheme that is both
internally consistent and consistent with the majority opinion.



 and also with regards to making non-property functions verbs (e.g.
 absolutePath and relativePath).


I'd be happy to change it, but I'm at loss for good alternatives.  I seem
to remember you suggesting makeAbsolute and makeRelative, but not being
100% happy with them yourself.  Any other suggestions?


I tend to like the current naming scheme.  I tried taking the list of 
functions and turning them into verbs, resulting in names like 
toAbsolute, ensureExtension, getBaseName, etc.  It makes it a bit easier 
to tell what's a function and what's not.  But given just a little bit 
of context, that's usually pretty clear.  Then those "to" and "get" 
prefixes start to feel like more like noise.


Leaving out prefixes in some cases leaves more room for making the names 
descriptive.  I guess that's another way of seeing it, so I thought I'd 
mention it.  It makes it a bit harder to get an overview of the module 
by reading the symbol list at the top of the doc page, though.



 Aside from that, wasn't it discussed that extensions should include the
 . in them in order to cover the case where a file ends in a .? Otherwise

 assert(extension("file.") == extension("file"));

 So, all of the stuff dealing with extensions should probably include the
 dot in the extension. It looks like both the current std.path and your
 std.path handle it by using "" for dot and null for nothing, but
 distinguishing between null and the empty string like that isn't
 necessarily a good idea, and your documentation doesn't make the
 distinction clear, unlike the documentation for the current std.path.

 So, at minimum, the docs should be clearer about null vs empty when it
 comes to the extension (and there should be tests for it), but it would
 arguably be better to just include the . in the extension.


I'm slowly coming around to the idea of including the dot.  Unless I hear
any loud protests I will probably do so.


I mentioned this in the other thread, but I'm hard pressed to find an 
actual use case for it.  The only thing I can think of is that with some 
Windows applications specifying a file name that ends with a dot will 
suppress the addition of a default extension.  Notepad is an example, it 
adds .txt by default.  I'm not sure if that's really relevant, though.


On Windows, I believe it's generally true that a file name that ends 
with a dot is not considered to have an extension.  You can't normally 
create a file name ending with a dot, IIRC, fopen() will just ignore the 
dot and create the file without it.  In light of that, I think the 
current behavior of extension() makes perfect sense.  I the rare case 
that a file name ending with a dot exists on the file system, it could 
easily fool naive user code that would likely never have seen such a 
file name in testing:


---
if (extension(fname).length == 0) {
writeln("Missing extension, adding default!);
setExtension(fname, "xyz");
}
---

Returning null for the special case of a name ending with a dot seems 
reasonable, I'm fine with that.  A slightly obscure solution for a 
slightly obscure problem.


I think setExtension could be smarter, same goes for defaultExtension. 
This is what I think they should behave like:


assert(setExtension("foo", "bar")   == "foo.bar");
assert(setExtension("foo", ".bar")  == "foo.bar");
assert(setExtension("foo.", "bar")  == "foo.bar");
assert(setExtension("foo.", ".bar") == "foo.bar");

This is what .NET does.  It's treating extensions not just like 
substrings, but recognizing that there is syntax and conventions 
associated with them.  Which is what you want 90% of the time.


Just my pragmatic, Windows-sentric view of things :)

Re: std.path review: second update

[Jonathan M Davis]

> On 01.08.2011 20:06, Lars T. Kyllingstad wrote:
> > On Mon, 01 Aug 2011 17:24:14 +, Jonathan M Davis wrote:
> >>> Here's a new update based on your comments and requests. Code and docs
> >>> are in the usual place,
> >>> [...]
> >> 
> >> Well, my previous comments on function names still stand - both in
> >> terms of names using Ext instead of Extension and Sep instead of sep -
> > 
> > Since the feedback has been minimal since my last update, I take it
> > people are more or less happy with the module's functionality now.
> > (Unless they're just tired of the whole discussion, of course. ;))
> > 
> > That means it is time to let the bikeshedding begin. Since we have been
> > unable to reach a consensus in previous discussions, and there are now
> > only three days left of the review, I would really like to get a good
> > sample of the general opinion here.
> > 
> > Folks, please state your preferences in terms of function names. I'll
> > try to put personal bias aside and compose a naming scheme that is both
> > internally consistent and consistent with the majority opinion.
> > 
> >> and also with regards to making non-property functions verbs (e.g.
> >> absolutePath and relativePath).
> > 
> > I'd be happy to change it, but I'm at loss for good alternatives. I seem
> > to remember you suggesting makeAbsolute and makeRelative, but not being
> > 100% happy with them yourself. Any other suggestions?
> 
> I tend to like the current naming scheme. I tried taking the list of
> functions and turning them into verbs, resulting in names like
> toAbsolute, ensureExtension, getBaseName, etc. It makes it a bit easier
> to tell what's a function and what's not. But given just a little bit
> of context, that's usually pretty clear. Then those "to" and "get"
> prefixes start to feel like more like noise.
> 
> Leaving out prefixes in some cases leaves more room for making the names
> descriptive. I guess that's another way of seeing it, so I thought I'd
> mention it. It makes it a bit harder to get an overview of the module
> by reading the symbol list at the top of the doc page, though.
> 
> >> Aside from that, wasn't it discussed that extensions should include the
> >> . in them in order to cover the case where a file ends in a .?
> >> Otherwise
> >> 
> >> assert(extension("file.") == extension("file"));
> >> 
> >> So, all of the stuff dealing with extensions should probably include
> >> the dot in the extension. It looks like both the current std.path and
> >> your std.path handle it by using "" for dot and null for nothing, but
> >> distinguishing between null and the empty string like that isn't
> >> necessarily a good idea, and your documentation doesn't make the
> >> distinction clear, unlike the documentation for the current std.path.
> >> 
> >> So, at minimum, the docs should be clearer about null vs empty when it
> >> comes to the extension (and there should be tests for it), but it would
> >> arguably be better to just include the . in the extension.
> > 
> > I'm slowly coming around to the idea of including the dot. Unless I hear
> > any loud protests I will probably do so.
> 
> I mentioned this in the other thread, but I'm hard pressed to find an
> actual use case for it. The only thing I can think of is that with some
> Windows applications specifying a file name that ends with a dot will
> suppress the addition of a default extension. Notepad is an example, it
> adds .txt by default. I'm not sure if that's really relevant, though.
> 
> On Windows, I believe it's generally true that a file name that ends
> with a dot is not considered to have an extension. You can't normally
> create a file name ending with a dot, IIRC, fopen() will just ignore the
> dot and create the file without it. In light of that, I think the
> current behavior of extension() makes perfect sense. I the rare case
> that a file name ending with a dot exists on the file system, it could
> easily fool naive user code that would likely never have seen such a
> file name in testing:
> 
> ---
> if (extension(fname).length == 0) {
> writeln("Missing extension, adding default!);
> setExtension(fname, "xyz");
> }
> ---
> 
> Returning null for the special case of a name ending with a dot seems
> reasonable, I'm fine with that. A slightly obscure solution for a
> slightly obscure problem.
> 
> I think setExtension could be smarter, same goes for defaultExtension.
> This is what I think they should behave like:
> 
> assert(setExtension("foo", "bar") == "foo.bar");
> assert(setExtension("foo", ".bar") == "foo.bar");
> assert(setExtension("foo.", "bar") == "foo.bar");
> assert(setExtension("foo.", ".bar") == "foo.bar");
> 
> This is what .NET does. It's treating extensions not just like
> substrings, but recognizing that there is syntax and conventions
> associated with them. Which is what you want 90% of the time.
> 
> Just my pragmatic, Windows-sentric view of things :)

The problem with that is that then you _can't_ have something like "f

Re: What library functionality would you most like to see in D?

[filgood]

On 31/07/2011 22:15, Brian Hay wrote:

On 31/07/2011 9:51 PM, Peter Alexander wrote:

My wish list:

- A good allocator model and integration with standard containers
- Fast vector math library suitable for games.


+1 vector math lib.
+1 for a good math lib (it would be cool if Scid cool become part of 
phobos after GSOC project)


also:
standard database lib (including bindings for postgresql, sqlite, etc)
gui lib (DWT2?)

thanks,

filgood

Re: std.path review: second update

[Jonathan M Davis]

> On Mon, 01 Aug 2011 17:24:14 +, Jonathan M Davis wrote:
> >> Here's a new update based on your comments and requests. Code and docs
> >> are in the usual place,
> >> [...]
> > 
> > Well, my previous comments on function names still stand - both in terms
> > of names using Ext instead of Extension and Sep instead of sep -
> 
> Since the feedback has been minimal since my last update, I take it
> people are more or less happy with the module's functionality now.
> (Unless they're just tired of the whole discussion, of course. ;))
> 
> That means it is time to let the bikeshedding begin. Since we have been
> unable to reach a consensus in previous discussions, and there are now
> only three days left of the review, I would really like to get a good
> sample of the general opinion here.
> 
> Folks, please state your preferences in terms of function names. I'll
> try to put personal bias aside and compose a naming scheme that is both
> internally consistent and consistent with the majority opinion.

If you want much feedback, you're probably going to need a new thread for 
that. I think that most people looked at the initial std.path implementation 
that you gave, had their say, and moved on. It wouldn't entirely surprise me 
if you could get away with making some incredibly stupid changes and then get 
them merged into Phobos simply because next to no one really looked at your 
most recent changes (I would hope that you wouldn't do that though).

> > and also with regards to making non-property functions verbs (e.g.
> > absolutePath and relativePath).
> 
> I'd be happy to change it, but I'm at loss for good alternatives. I seem
> to remember you suggesting makeAbsolute and makeRelative, but not being
> 100% happy with them yourself. Any other suggestions?

I'd just go with makeAbsolute and makeRelative. Maybe makeAbolutePath and 
makeRelativePath (or makeAbsPath and makeRelPath) would be better, but those 
are getting a bit long.

It's defaultExtension which is problematic (aside from the fact that I think 
that Extension should be shortened to Ext). What it's trying to do is set the 
extension with a default extension if one isn't set but do nothing if it is, 
and I can't think of a good name for that. setExtToDefaultIfNoExt just doesn't 
roll off the tongue. ;)

So, I don't have a good fix for defaultExtension, but I think that going with 
makeAbsolute and makeRelative would be better, since they _do_ make sense and 
are proper verbs.

- Jonathan M Davis

Re: What library functionality would you most like to see in D?

[Johann MacDonagh]

On 7/31/2011 11:32 PM, Walter Bright wrote:

On 7/31/2011 6:29 PM, Johann MacDonagh wrote:

Basically, you give it some string (string, wstring, or dstring), and
it gives
you a range of tokens back. The token has the type, a slice of the
input that
corresponds to the token, line / column, and a value (e.g. an integer
constant).


I suggest making the input a range.


So, the reason I didn't do this initially was to make slicing a lot 
easier. It could easily be changed to any kind of input range of 
characters. However, it looks like something that's not a direct port of 
DMD isn't worthwhile.

Re: What library functionality would you most like to see in D?

[Nick Sabalausky]

"Johann MacDonagh"  wrote in message 
news:j1501g$tbs$1...@digitalmars.com...
>
> 1. Database interface. Should support sqlite, mysql, postgres, etc...
> 3. Some kind of web framework.

Agreed, but fortunately Adam's stuff for that is shaping up nicely:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff

> 2. DWT fixed up and merged into Phobos.

That'd certainly be nice.

Re: What library functionality would you most like to see in D?

[Nick Sabalausky]

"Alex Rønne Petersen"  wrote in message 
news:j1395t$13bo$1...@digitalmars.com...
> On 31-07-2011 11:57, Jacob Carlborg wrote:
>> I think someone is working on this.
>
> I know of the Goldie project. Is this it?
>

I'm very interested in doing what I can to make Goldie suitable for what 
people need. Are there any particular shortcomings you see with it?

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

> On 7/31/2011 11:32 PM, Walter Bright wrote:
> > On 7/31/2011 6:29 PM, Johann MacDonagh wrote:
> >> Basically, you give it some string (string, wstring, or dstring), and
> >> it gives
> >> you a range of tokens back. The token has the type, a slice of the
> >> input that
> >> corresponds to the token, line / column, and a value (e.g. an integer
> >> constant).
> > 
> > I suggest making the input a range.
> 
> So, the reason I didn't do this initially was to make slicing a lot
> easier. It could easily be changed to any kind of input range of
> characters. However, it looks like something that's not a direct port of
> DMD isn't worthwhile.

Some adjustment can be made. It _does_ need to have a range-based API, and 
some changes are inevitable in order to do that. But the changes to the basic 
logic need to be minimal.

The thing is that it can be an input range _and_ take advantage of slicing 
with the use of static ifs in the appropriate places. If hasSlicing!Range is 
true, then you can have a static if branch for slicing it. If it's a narrow 
string then you can use another branch. And if it's neither, then it won't get 
the advantages of slicing. It complicates the code somewhat, but the proper 
use of Phobos functions which deal with it for you should help.

In any case, the point is that we need to port dmd's lexer over to D, changing 
it enough to give it a range-based interface (so it'll take a range of dchars 
but return a range of tokens) but avoiding changing more than necessary so 
that it's easy to port changes and fixes back and forth between it and dmd's 
front end.

- Jonathan M Davis

Re: What library functionality would you most like to see in D?

[Nick Sabalausky]

"bearophile"  wrote in message 
news:j13mhm$1prf$1...@digitalmars.com...
> - std.image: module to read and write png, jpeg, gif, bmp, ppm images;

That'd be very nice to have in phobos.

Re: std.path review: second update

[Nick Sabalausky]

"Lars T. Kyllingstad"  wrote in message 
news:j16pv5$id8$3...@digitalmars.com...
>
> Folks, please state your preferences in terms of function names.  I'll
> try to put personal bias aside and compose a naming scheme that is both
> internally consistent and consistent with the majority opinion.
>

I'm happy either way with Sep/Ext or Separator/Extension. I guess my 
preference would be for the shorter versions. They're perfectly clear (who 
isn't familiar with the "ext" abbreviation for "extension"?) and they're 
easier to spell. And one-line file/path manipulations are less likely to 
grow too far past the 80-char mark. But if we kept the long ones, I wouldn't 
complain.

>
>> and also with regards to making non-property functions verbs (e.g.
>> absolutePath and relativePath).
>
> I'd be happy to change it, but I'm at loss for good alternatives.  I seem
> to remember you suggesting makeAbsolute and makeRelative, but not being
> 100% happy with them yourself.  Any other suggestions?
>

I agree with "function names should be verbs" as a general guideline, but I 
don't think it should be taken so strictly that it gets forced on in 
situations (like this one) where it just doesn't work quite as well. Despite 
not being verbs, "absolutePath/relativePath" are perfectly clear and much 
more descriptive than "makeAbsolute/makeRelative" (Make an absolute or 
relative what?). And then "makeAbsolutePath/makeRelativePath" is just 
starting to get verbose.

I think this is one case where it's just not worthwhile to force the 
"function names should be verbs" guideline.

>
> I'm slowly coming around to the idea of including the dot.  Unless I hear
> any loud protests I will probably do so.
>

Sounds good to me.

Re: What does C++ do better than D? - StackOverflow.com

[Peter Alexander]

On 1/08/11 7:29 PM, Kagamin wrote:

Walter Bright Wrote:


Now on reddit!

http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/


C++ has a better thought out type system.
Nice joke.
http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html


Please read my note at the end. I believe D (probably) has a better type 
system. It just wasn't very well though out.


I believe many aspects of D's type system were added in without fully 
exploring the ramifications they had on other parts of the language. 
There are at least two pieces of evidence which support my belief:


1. The fact that you can't copy const struct objects containing 
reference types.


2. The fact that the root object still isn't const correct.


C++ has some questionable choices for its type system, but it generally 
doesn't prevent you from getting work done.

Re: Fixing enum names in Phobos

[Michal Minich]

On Mon, 01 Aug 2011 05:56:22 +, %u wrote:

> How do you plan on camelCasing pure, nothrow, out, ref, etc?

simply add exception to the camelCase rule: if word is keyword, use 
PascalCase. 

IMO, easier to remember and to the eyes than any kind of ad-hoc pre/sufix.

Re: Still cannot build Phobos from git

[Nick Sabalausky]

"Jacob Carlborg"  wrote in message 
news:j15la3$1vl9$1...@digitalmars.com...
> On 2011-07-31 22:26, Nick Sabalausky wrote:
>> "Jacob Carlborg"  wrote in message
>> news:j139bn$13bj$2...@digitalmars.com...
>>> On 2011-07-31 11:31, Nick Sabalausky wrote:

 I was going to go through tango.sys.Process to use the cmdline git to
 grab
 it. Is there a way to just download a zip from github without going
 through
 git? That would be better, since it wouldn't require the user have git
 installed, but I don't know of a way to do that.
>>>
>>> You see the big "Downloads" button on every github project? Click on 
>>> that,
>>> there you can get a link to a zip file containing the sources, URL for
>>> Phobos: https://github.com/D-Programming-Language/phobos/zipball/master
>>>
>>
>> I'd already tried the "Downloads" button, but it only gives me the 
>> releases.
>> The, umm..."trunk"/head/master/whatever isn't listed there.
>
> If I click the "Downloads" button I get a popup window with "Download 
> source" and "Download packages". "Download source" is the current head, 
> "Download packages" contains tags. BTW, I'm pretty sure it requires 
> javascript to get the popup.
>

My instinctual reaction to "pop-ins" (I **HATE**, **HATE**, **HATE** 
pop-ins - they're even *worse* than pop-ups) is to curse, disable JS, and 
reload. The resulting page, allegedly, shows "all" downloads, but the 
non-tag ones are missing from it.

Of course, in this case, I did actually read what was on the pop-in before 
going all Nick on it, but it wasn't remotely clear to me that "Download 
source", "Download .tar.gz" or "Download .zip" really meant "current head" 
(actually, I didn't even suspect that it might have meant that - I didn't 
know what the hell they were referring to and I didn't want to assume.)

Re: What library functionality would you most like to see in D?

[Andrei Alexandrescu]

On 8/1/11 4:35 PM, Nick Sabalausky wrote:

"Johann MacDonagh"  wrote in message
news:j1501g$tbs$1...@digitalmars.com...


1. Database interface. Should support sqlite, mysql, postgres, etc...
3. Some kind of web framework.


Agreed, but fortunately Adam's stuff for that is shaping up nicely:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff


2. DWT fixed up and merged into Phobos.


That'd certainly be nice.


Interesting. What platforms does DWT work on? What is the general 
community opinion on integrating it within Phobos? Is there anyone 
willing to take on this task?


Thanks,

Andrei

Re: Still cannot build Phobos from git

[Walter Bright]

On 7/27/2011 1:34 PM, bearophile wrote:

Dmitry Olshansky:


My recipe on Windows:


I presume it has tens of quite different kinds of ways to fail :-)

This is what I see:


You need to use Digital Mars make, the one that comes with dmd:

http://www.digitalmars.com/ctg/make.html

Re: D question on bioinformatics stackexchange site

[Caligo]

On Mon, Aug 1, 2011 at 1:38 PM, David Nadlinger  wrote:

> David Simcha (and others working on bioinformatics), you might want to
> chime in on this:
>
> http://biostar.stackexchange.**com/questions/10785/what-**
> bioinformatics-software-is-**there-written-in-d
>
> David
>


Is that a fake site?  The bioinformatics site on stackexchange hasn't been
created yet.
http://area51.stackexchange.com/proposals/6729/bioinformatics

Re: What does C++ do better than D? - StackOverflow.com

[Timon Gehr]

On 1/08/11 7:29 PM, Kagamin wrote:
> Walter Bright Wrote:
>
>> Now on reddit!
>>
>> http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/
>
> C++ has a better thought out type system.
> Nice joke.
> http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html
>
> Please read my note at the end. I believe D (probably) has a better type
> system. It just wasn't very well though out.
>
> I believe many aspects of D's type system were added in without fully
> exploring the ramifications they had on other parts of the language.
> There are at least two pieces of evidence which support my belief:
>
> 1. The fact that you can't copy const struct objects containing
> reference types.

You can copy them, but not to mutable. In exchange, you get transitive const.

>
> 2. The fact that the root object still isn't const correct.
>

I think it could be. It would just force everyone implementing opEquals to be
const correct too. Or is there any other fundamental issue?

>
> C++ has some questionable choices for its type system, but it generally
> doesn't prevent you from getting work done.

I have not yet been affected by any of your two issues. Do you have example use
cases where they prevent you from getting work done?

-Timon

Re: What does C++ do better than D? - StackOverflow.com

[Adam Ruppe]

Peter Alexander wrote:
> 1. The fact that you can't copy const struct objects containing
> reference types.

I recently hit a similar problem. web.d uses a ParameterTypeTuple
to fill in arguments to the functions it calls in a generic way.

With "in" arguments, assigning to the tuple isn't allowed! It says
"can't modify const".

I decided to just not use const in there, and cast it away in the
wrapper function. I'm not happy with that, but I don't know what else
to do. (I generally like D's const and immutable, but blarg there are
some rough edges and I don't even know how to fix the design.)

Re: What does C++ do better than D? - StackOverflow.com

[Jonathan M Davis]

> On 1/08/11 7:29 PM, Kagamin wrote:
> > Walter Bright Wrote:
> >> Now on reddit!
> >> 
> >> http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_
> >> d/
> > 
> > C++ has a better thought out type system.
> > Nice joke.
> > http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html
> 
> Please read my note at the end. I believe D (probably) has a better type
> system. It just wasn't very well though out.
> 
> I believe many aspects of D's type system were added in without fully
> exploring the ramifications they had on other parts of the language.
> There are at least two pieces of evidence which support my belief:
> 
> 1. The fact that you can't copy const struct objects containing
> reference types.
> 
> 2. The fact that the root object still isn't const correct.
> 
> 
> C++ has some questionable choices for its type system, but it generally
> doesn't prevent you from getting work done.

C++ is also a lot older. It's had more time to sort out its type system. It 
also has a simpler type system. So, any issues that it had have long since 
been resolved. D just hasn't had the same time to sort through all of the 
issues in its type system. It'll get there soon enough though.

- Jonathan M Davis

Re: What does C++ do better than D? - StackOverflow.com

[Jonathan M Davis]

> On 1/08/11 7:29 PM, Kagamin wrote:
> > Walter Bright Wrote:
> >> Now on reddit!
> >> 
> >> http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_
> >> d/
> > 
> > C++ has a better thought out type system.
> > Nice joke.
> > http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html
> > 
> > Please read my note at the end. I believe D (probably) has a better type
> > system. It just wasn't very well though out.
> > 
> > I believe many aspects of D's type system were added in without fully
> > exploring the ramifications they had on other parts of the language.
> > There are at least two pieces of evidence which support my belief:
> > 
> > 1. The fact that you can't copy const struct objects containing
> > reference types.
> 
> You can copy them, but not to mutable. In exchange, you get transitive
> const.
> 
> > 2. The fact that the root object still isn't const correct.
> 
> I think it could be. It would just force everyone implementing opEquals to
> be const correct too. Or is there any other fundamental issue?

The primary issues are actually doing the work to make it const-correct and 
the fact that if the compiler's handling of const is buggy, it could really 
screw over Object - and thus all classes. So, the bug has sat there for a long 
time. I'm not sure that there are really any issues with it at this point 
other than taking the time to do it though.

> > C++ has some questionable choices for its type system, but it generally
> > doesn't prevent you from getting work done.
> 
> I have not yet been affected by any of your two issues. Do you have example
> use cases where they prevent you from getting work done?

You lose logical const, which he has wanted to use in stuff that he's been 
doing (games I think). He wants to lazy load values in his objects. You can't 
do that with D's const. It pretty much means that that you have to either 
eager load it or give up on const. It's totally doable, but it forces you to 
change your design in a manner which you might not like.

- Jonathan M Davis

pi benchmark on ldc and dmd

[Walter Bright]

http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98

Anyone care to examine the assembler output and figure out why?

DWT in Phobos? was [Re: What library functionality would you most like to see in D?]

[Jesse Phillips]

Andrei Alexandrescu Wrote:

> On 8/1/11 4:35 PM, Nick Sabalausky wrote:
> > "Johann MacDonagh"  wrote in message
> >> 2. DWT fixed up and merged into Phobos.
> >
> > That'd certainly be nice.
> 
> Interesting. What platforms does DWT work on? What is the general 
> community opinion on integrating it within Phobos? Is there anyone 
> willing to take on this task?
> 
> Thanks,
> 
> Andrei

I think DWT for D2 worked with Windows and Linux (tested on).

The port is very Java style, it doesn't have a D layer to make it work nicely 
with ranges (err last time I used it 3 yrs ago). All the packages are 
org.eclipse... The library itself is huge and the port isn't complete.

It probably isn't a good idea to bring it into Phobos since it needs to be easy 
to keep up with SWT development. However it might be reasonable to take DWT, 
mold it into a D like library and continue development separate from SWT. I 
don't know if that is easier than developing a D2 GUI library from scratch, but 
having such a library in Phobos is probably a *great* idea.

Re: What does C++ do better than D? - StackOverflow.com

[Walter Bright]

On 8/1/2011 4:36 PM, Jonathan M Davis wrote:

You lose logical const, which he has wanted to use in stuff that he's been
doing (games I think). He wants to lazy load values in his objects. You can't
do that with D's const. It pretty much means that that you have to either
eager load it or give up on const. It's totally doable, but it forces you to
change your design in a manner which you might not like.


I've talked to many people who use logical const extensively in C++, and really 
want it. If you dig down into what's happening, you'll find that logical const 
isn't actually supported by C++. It's a convention. There's simply nothing in 
the language that enforces that convention.


The reason "logical const" does not work with const in D is because D actually 
enforces const semantics, and relies on that enforcement.


Since logical const is a convention in C++ anyway, you can have logical const in 
D, too. Just put in a comment:


   struct S /* This struct is logical const */
   { ... }

and then follow the convention just as you would with C++.

Const in C++ is not powerful - it's simply a fraud - and the two get confused.

Re: What library functionality would you most like to see in D?

[Piotr Szturmaj]

Jonathan M Davis wrote:

I think that it would be useful to query the community for what piece of
library functionality they don't currently have in D and would most like to
see. For instance, there is no official logging framework in D or any 3rd party
libraries which do it AFAIK. So, that could be one type of functionality that
you may like to see. Now, there is a prospective implementation for std.log
which shouldn't be all that far away from being reviewed, so listing that here
wouldn't be all that useful, since it's on its way. But what other major
functionality do you miss in D that other languages' that you use have
available in their libraries?

My hope here would be that we could get some good ideas going here such that
we have can have a better idea what type of functionality it would be
particularly useful to be working on for Phobos or 3rd party D libraries for
the community, and maybe it'll even get some people to actually go and work on
these ideas so that we can improve the libraries that we have to work with in
D. We can always use more help, and we definitely need a richer library
ecosystem for D. But even just discussing ideas could be of benefit.

So, what major functionality which we don't currently have would you like to
see in either Phobos or in a 3rd party library so that you could use it in
your D programs?

- Jonathan M Davis


1. Cryptography (I already wrote all SHA hash implementations and HMAC, 
they will be open sourced under Boost license, I'm also working on 
Rijndael/AES impl.)


some of the proposed namespaces (just thinking loud):

std.crypto.cipher - block and stream ciphers
std.crypto.hash - message digests (SHA1, RIPEMD, ...)
std.crypto.mac - message auth codes like HMAC, CMAC, UMAC
std.crypto.mode - block cipher modes like CBC, GCM, ...
std.crypto.padding - padding schemes
std.crypto.pki - asymmetric cryptography (RSA), PKI
std.crypto.x509 - certificate support

2. Easy to use non-GC threads for soft real time support. Non-GC threads 
must not be suspended by the GC and they must support some kind of 
reliable communication with normal (GC) threads. This should be similar 
to IPC, where there's no shared memory between GC and non-GC threads.


Consider running two separate programs, one written in D with GC support 
and one written in plain C. These programs communicate with each other 
using some IPC mechanism. The latter is never suspended.
The whole point is to make equivalent of this configuration in a single 
executable using mixture of GC and non-GC threads.

Re: What does C++ do better than D? - StackOverflow.com

[Jonathan M Davis]

> On 8/1/2011 4:36 PM, Jonathan M Davis wrote:
> > You lose logical const, which he has wanted to use in stuff that he's
> > been doing (games I think). He wants to lazy load values in his objects.
> > You can't do that with D's const. It pretty much means that that you
> > have to either eager load it or give up on const. It's totally doable,
> > but it forces you to change your design in a manner which you might not
> > like.
> 
> I've talked to many people who use logical const extensively in C++, and
> really want it. If you dig down into what's happening, you'll find that
> logical const isn't actually supported by C++. It's a convention. There's
> simply nothing in the language that enforces that convention.
> 
> The reason "logical const" does not work with const in D is because D
> actually enforces const semantics, and relies on that enforcement.
> 
> Since logical const is a convention in C++ anyway, you can have logical
> const in D, too. Just put in a comment:
> 
> struct S /* This struct is logical const */
> { ... }
> 
> and then follow the convention just as you would with C++.
> 
> Const in C++ is not powerful - it's simply a fraud - and the two get
> confused.

You do get some gains from const in C++, but it's pretty much all gained by 
convention. It _is_ better than just comments in that the compiler will 
complain if you break the convention, forcing you to explicitly break it (e.g. 
via casting or mutable), but ultimately, it doesn't enforce much. I do believe 
that it enforces enough that it's worth having, but it obviously doesn't 
provide the guarantees that D's const does.

It seems to me that it would be possible to have logical const in D - at least 
as far as lazy loading goes - if a feature were added to allow for a member 
variable to be set the first time that it's accessed (you've essentially just 
delayed the initialization of that particular variable). Obviously, it would 
have to be disallowed when immutable is involved (or eagerly loaded in the 
case of immutable). Syntactically, it would probably be something like

lazy int var = initializeFunc();

The initialization then takes place when var is first used rather than at 
compile time.

Now, that could be very nasty to implement, and I'm not at all suggesting that 
we consider such a feature right now (if anything, it would probable be a D3 
feature), but it seems to me that it should be posible to add a mechanism to 
the language specifically for the lazy loading of member variables which 
worked even when the first time that the variable was accessed was in a const 
function. Whether it's worth the time and effort it would take to implement 
it, let alone the complication that it would add to the language, I don't 
know. But it's at least theoretically possible.

The reality of the situation at the moment though is that D actually fully 
enforces const (unlike C++), so it can't really even fake having logical const 
(unlike C++), so you just can't use const in some situations in D where you 
would in C++. It's certainly annoying sometimes, but in general, the gains far 
outweigh the cost IMHO.

- Jonathan M Davis

Re: What does C++ do better than D? - StackOverflow.com

[Walter Bright]

On 8/1/2011 5:07 PM, Jonathan M Davis wrote:

You do get some gains from const in C++, but it's pretty much all gained by
convention. It _is_ better than just comments in that the compiler will
complain if you break the convention, forcing you to explicitly break it (e.g.
via casting or mutable), but ultimately, it doesn't enforce much. I do believe
that it enforces enough that it's worth having, but it obviously doesn't
provide the guarantees that D's const does.


Any code at any time can modify a mutable member of a const object, without even 
bothering with the nicety of a cast. The notion that C++ "supports" logical 
const is without merit.

Re: dmd installer clobbers PATH on Windows (sometimes)

[Vladimir Panteleev]

On Tue, 02 Aug 2011 03:35:23 +0300, Vladimir Panteleev  
 wrote:



and boot from another OS


Sorry, forgot to add: or simply select the "last known good configuration"  
start-up option, you should boot with the old registry. This will probably  
clobber all system registry changes since then, though.


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: dmd installer clobbers PATH on Windows (sometimes)

[Vladimir Panteleev]

On Mon, 01 Aug 2011 20:58:08 +0300, Brad Anderson  wrote:

there is no way (that I know of) to look at what your PATH was before it  
was destroyed and the PATH is often updated by installers (as it is with  
dmd).


If you haven't rebooted your machine yet - Windows stores a backup copy of  
the system registry hives for the "last known good configuration" boot  
feature. These copies are stored in C:\Windows\Repair (XP and before) or  
C:\Windows\System32\config\RegBack (Vista and after). You will not be able  
to access these files directly, though - you'll need to use a tool or risk  
a poweroff and boot from another OS. Once you have a readable copy, you  
can "mount" the hives to an empty key in your registry with RegEdit. PATH  
is located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session  
Manager\Environment (though you won't see CurrentControlSet in the mounted  
hive, it's a symbolic link of sorts to one of the ControlSetXXX keys).


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: What library functionality would you most like to see in D?

[Brad Roberts]

On Mon, 1 Aug 2011, Andrei Alexandrescu wrote:

> On 8/1/11 4:35 PM, Nick Sabalausky wrote:
> > "Johann MacDonagh"  wrote in message
> > news:j1501g$tbs$1...@digitalmars.com...
> > > 
> > > 1. Database interface. Should support sqlite, mysql, postgres, etc...
> > > 3. Some kind of web framework.
> > 
> > Agreed, but fortunately Adam's stuff for that is shaping up nicely:
> > 
> > https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
> > 
> > > 2. DWT fixed up and merged into Phobos.
> > 
> > That'd certainly be nice.
> 
> Interesting. What platforms does DWT work on? What is the general community
> opinion on integrating it within Phobos? Is there anyone willing to take on
> this task?
> 
> Thanks,
> 
> Andrei

I don't think that any gui library belongs in phobos because there's 
essentially no agreement about what cross-platform library is standard.  
Pick any random 10 gui developers about what library they used (assuming 
they do anything cross-platform) and you'll get more than 1 answer.  I'd 
be shocked if you get a clear enough majority to suggest 1 that'd make a 
big set of people happy.

Sorry, the gui library landscape just doesn't approach being obvious 
enough to be in the standard library.

My 2 cents,
Brad

Re: What does C++ do better than D? - StackOverflow.com

[Jonathan M Davis]

> On 8/1/2011 5:07 PM, Jonathan M Davis wrote:
> > You do get some gains from const in C++, but it's pretty much all gained
> > by convention. It _is_ better than just comments in that the compiler
> > will complain if you break the convention, forcing you to explicitly
> > break it (e.g. via casting or mutable), but ultimately, it doesn't
> > enforce much. I do believe that it enforces enough that it's worth
> > having, but it obviously doesn't provide the guarantees that D's const
> > does.
> 
> Any code at any time can modify a mutable member of a const object, without
> even bothering with the nicety of a cast. The notion that C++ "supports"
> logical const is without merit.

If an object isn't const, you can't call anything on it that isn't const. That 
does gain you some level of safety which is enforced by the compiler. But 
since you can completely side step it via a cast (or by having a mutable 
member variable), you don't really get any guarantees. However, that minimal 
support _is_ still better than nothing IMHO. So, C++ supports const in that 
sense. But yes. You're right that logical const isn't much more than a 
convention. The fact that C++ has mutable helps support the convention, but 
it's still ultimately a convention. Still, the fact that the compiler does 
have some level of enforcement for const does add something of value.

- Jonathan M Davis

Re: What does C++ do better than D? - StackOverflow.com

[Brad Roberts]

On Mon, 1 Aug 2011, Peter Alexander wrote:

> On 1/08/11 7:29 PM, Kagamin wrote:
> > Walter Bright Wrote:
> > 
> > > Now on reddit!
> > > 
> > > http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/
> > 
> > C++ has a better thought out type system.
> > Nice joke.
> > http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html
> 
> Please read my note at the end. I believe D (probably) has a better type
> system. It just wasn't very well though out.
> 
> I believe many aspects of D's type system were added in without fully
> exploring the ramifications they had on other parts of the language. There are
> at least two pieces of evidence which support my belief:
> 
> 1. The fact that you can't copy const struct objects containing reference
> types.
> 
> 2. The fact that the root object still isn't const correct.
> 
> 
> C++ has some questionable choices for its type system, but it generally
> doesn't prevent you from getting work done.

You're mixing state of implementation with design of the type system.  
Easy enough to conflate, but still a conflation of issues.

Don't get me wrong, that there's QOI issues still is a real problem.  I'd 
also agree that it's in the top 10 list of real problems.  I don't know 
that I'd make it #1 on the list, though.  Please don't ask me what my #1 
issue is, it varies from week to week. :)

Until the QOI issues are worked out, or at least reduced significantly, 
it's not clear that we'll be able to make any strong statements about the 
quality of the design.

Later,
Brad

Re: What does C++ do better than D? - StackOverflow.com

[Walter Bright]

On 8/1/2011 5:58 PM, Jonathan M Davis wrote:

On 8/1/2011 5:07 PM, Jonathan M Davis wrote:

You do get some gains from const in C++, but it's pretty much all gained
by convention. It _is_ better than just comments in that the compiler
will complain if you break the convention, forcing you to explicitly
break it (e.g. via casting or mutable), but ultimately, it doesn't
enforce much. I do believe that it enforces enough that it's worth
having, but it obviously doesn't provide the guarantees that D's const
does.


Any code at any time can modify a mutable member of a const object, without
even bothering with the nicety of a cast. The notion that C++ "supports"
logical const is without merit.


If an object isn't const, you can't call anything on it that isn't const. That
does gain you some level of safety which is enforced by the compiler.


Those "const" functions can still change the mutable members without any cast.

Re: What does C++ do better than D? - StackOverflow.com

[Andrei Alexandrescu]

On 8/1/11 6:30 PM, Adam Ruppe wrote:

Peter Alexander wrote:

1. The fact that you can't copy const struct objects containing
reference types.


I recently hit a similar problem. web.d uses a ParameterTypeTuple
to fill in arguments to the functions it calls in a generic way.

With "in" arguments, assigning to the tuple isn't allowed! It says
"can't modify const".

I decided to just not use const in there, and cast it away in the
wrapper function. I'm not happy with that, but I don't know what else
to do. (I generally like D's const and immutable, but blarg there are
some rough edges and I don't even know how to fix the design.)


I know how to fix the design (in fact the implementation, the design is 
sound). It's just ever so difficult to find the time to prioritize for it.


Overall I feel Peter's post on stackexchange did more bad than good (of 
course that doesn't mean he had the right; I'm just writing this under 
the hypothesis he meant well and he'd be interested ). Within the 
confines of the community, discussing such issues is welcome and 
healthy. Mentioning these to the outside blows the issues out of 
proportion and conveys the wrong message to someone coming anew to D.


Plus, C++'s type system is marred by issues, so the statement has 
correctness issues to start with. Const is a mix of storage type and 
type qualifier; even most experts have no idea about that, and the 
minority of experts who do know about the distinction have difficulty 
figuring which is in effect when. Type deduction with functions and 
const is essentially a collection of special cases. Pointer to member 
functions have a type, but it can't be named, spelled, or used. 
Functions taking char* still accept string literals (compilers 
increasingly override that, but the rule is in the standard for C's 
sake). There is no way to convert a void* to a pointer to function, 
meaning all dynamic loading facilities must operate outside the 
standard. There is no way to specify or figure out alignment. Slicing 
polymorphic objects is legit. And so on and so forth.


C++'s type system problems have been trodden over a million times and 
they might have became as invisible as that carpet stain in the hallway. 
That doesn't mean they're not there.



Andrei

Re: What does C++ do better than D? - StackOverflow.com

[Jonathan M Davis]

On Monday 01 August 2011 18:02:11 Walter Bright wrote:
> On 8/1/2011 5:58 PM, Jonathan M Davis wrote:
> >> On 8/1/2011 5:07 PM, Jonathan M Davis wrote:
> >>> You do get some gains from const in C++, but it's pretty much all
> >>> gained by convention. It _is_ better than just comments in that the
> >>> compiler will complain if you break the convention, forcing you to
> >>> explicitly break it (e.g. via casting or mutable), but ultimately,
> >>> it doesn't enforce much. I do believe that it enforces enough that
> >>> it's worth having, but it obviously doesn't provide the guarantees
> >>> that D's const does.
> >> 
> >> Any code at any time can modify a mutable member of a const object,
> >> without even bothering with the nicety of a cast. The notion that C++
> >> "supports" logical const is without merit.
> > 
> > If an object isn't const, you can't call anything on it that isn't
> > const. That does gain you some level of safety which is enforced by the
> > compiler.
> Those "const" functions can still change the mutable members without any
> cast.

Yes. I agree with you that C++ does not ultimately give you any guarantees, 
because you can use casting and mutable to completely circumvent const. 
However, I disagree with you if you think that const in C++ isn't ultimately 
any better than commenting your code to say that it's const. The compiler does 
enforce const on some level - it just gives you ways to completely circumvent 
it if you want to - so while it is ultimately a convention, it is on some 
level a compiler-enforced convention. So, it's better than comments. That's 
all I'm really trying to say.

Just the other day, the fact that I use const heavily in C++ helped me catch 
bugs in my code where I had gotten the arguments to algorithm's copy function 
backwards. The fact that the source was const made it so that copy didn't 
compile. Without const, I would have had a much harder time catching my 
mistake.

So yes. It's ultimately a fallacy to say that C++ has logical const. However, 
that doesn't mean that const in C++ is useless. And your posts on it at least 
give the impression that that's what you think. It does not give the same 
guarantees as D's const, but it does give you some (albeit much weaker 
guarantees) and is better than nothing.

- Jonathan M Davis

Re: pi benchmark on ldc and dmd

[bearophile]

Walter:

> http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98
> 
> Anyone care to examine the assembler output and figure out why?

Do you mean code similar to this one, or code that uses std.bigint?
http://shootout.alioth.debian.org/debian/program.php?test=pidigits&lang=gdc&id=3

Bye,
bearophile

Re: int[3] a = [1, 2, 3]; // Why heap?

[Mehrdad]

On 8/1/2011 6:32 AM, Don wrote:

Mehrdad wrote:

I'm just wondering, is there a plan to fix the

|int[3] a = [1, 2, 3];
|

issue, to not make it allocate on the heap?

It kind of sucks to see people bash D for something so trivial like 
this. :\


Yes. It's bug 2356.


Ah ok thanks!

Re: What does C++ do better than D? - StackOverflow.com

[bearophile]

Andrei:

> Mentioning these to the outside blows the issues out of 
> proportion and conveys the wrong message to someone coming anew to D.

This is often true, unfortunately. But doing the opposite too has risks. If you 
keep saying only good things about a very complex systems X, people naturally 
start getting suspicious, because simply a so much complex system can't be 
perfect.

Such threads are always very messy. They are full of errors, good ideas, and 
everything else. I hope people do not believe everything said in such threads, 
both bad and good things. It's like a room full of people shouting, where half 
of them don't know what they are talking about :-)


> Plus, C++'s type system is marred by issues,

This is good information to know, thank you. I think most people need to write 
non obvious programs (like library code) both in C++ and D to understand some 
of the C++ problems you list, otherwise I think lot of programmers have 
difficulties understanding them in abstract, and they think D doesn't improve 
the situation enough compared to C++0x. D contains many improvements that are 
not easy to see. More articles that show D usage (compared to C++ too) are 
probably going to improve this a bit.

Bye,
bearophile

Re: What does C++ do better than D? - StackOverflow.com

[Andrei Alexandrescu]

On 8/1/11 9:09 PM, bearophile wrote:

Andrei:


Mentioning these to the outside blows the issues out of proportion
and conveys the wrong message to someone coming anew to D.


This is often true, unfortunately. But doing the opposite too has
risks. If you keep saying only good things about a very complex
systems X, people naturally start getting suspicious, because simply
a so much complex system can't be perfect.


I didn't advocate the opposite, and I don't think my response on SE was 
only discussing the shiny city on the hill.


Andrei

Re: What does C++ do better than D? - StackOverflow.com

[Andrei Alexandrescu]

On 8/1/11 8:29 PM, Andrei Alexandrescu wrote:

On 8/1/11 6:30 PM, Adam Ruppe wrote:

Peter Alexander wrote:

1. The fact that you can't copy const struct objects containing
reference types.


I recently hit a similar problem. web.d uses a ParameterTypeTuple
to fill in arguments to the functions it calls in a generic way.

With "in" arguments, assigning to the tuple isn't allowed! It says
"can't modify const".

I decided to just not use const in there, and cast it away in the
wrapper function. I'm not happy with that, but I don't know what else
to do. (I generally like D's const and immutable, but blarg there are
some rough edges and I don't even know how to fix the design.)


I know how to fix the design (in fact the implementation, the design is
sound). It's just ever so difficult to find the time to prioritize for it.

Overall I feel Peter's post on stackexchange did more bad than good (of
course that doesn't mean he had the right;


s/had/didn't have/


Andrei

Re: What does C++ do better than D? - StackOverflow.com

[Andrei Alexandrescu]

On 8/1/11 7:56 PM, Brad Roberts wrote:

On Mon, 1 Aug 2011, Peter Alexander wrote:


On 1/08/11 7:29 PM, Kagamin wrote:

Walter Bright Wrote:


Now on reddit!

http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/


C++ has a better thought out type system.
Nice joke.
http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html


Please read my note at the end. I believe D (probably) has a better type
system. It just wasn't very well though out.

I believe many aspects of D's type system were added in without fully
exploring the ramifications they had on other parts of the language. There are
at least two pieces of evidence which support my belief:

1. The fact that you can't copy const struct objects containing reference
types.

2. The fact that the root object still isn't const correct.


C++ has some questionable choices for its type system, but it generally
doesn't prevent you from getting work done.


You're mixing state of implementation with design of the type system.
Easy enough to conflate, but still a conflation of issues.

Don't get me wrong, that there's QOI issues still is a real problem.  I'd
also agree that it's in the top 10 list of real problems.  I don't know
that I'd make it #1 on the list, though.  Please don't ask me what my #1
issue is, it varies from week to week. :)

Until the QOI issues are worked out, or at least reduced significantly,
it's not clear that we'll be able to make any strong statements about the
quality of the design.

Later,
Brad


Good point, particularly when you compare it with the QOI issues in C++ 
as it was maturing. And the design, too. There were times when e.g. 
nobody knew when an object ought to be destroyed.


Andrei

Re: What library functionality would you most like to see in D?

[Andrei Alexandrescu]

On 8/1/11 7:51 PM, Brad Roberts wrote:

On Mon, 1 Aug 2011, Andrei Alexandrescu wrote:


On 8/1/11 4:35 PM, Nick Sabalausky wrote:

"Johann MacDonagh"   wrote in message
news:j1501g$tbs$1...@digitalmars.com...


1. Database interface. Should support sqlite, mysql, postgres, etc...
3. Some kind of web framework.


Agreed, but fortunately Adam's stuff for that is shaping up nicely:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff


2. DWT fixed up and merged into Phobos.


That'd certainly be nice.


Interesting. What platforms does DWT work on? What is the general community
opinion on integrating it within Phobos? Is there anyone willing to take on
this task?

Thanks,

Andrei


I don't think that any gui library belongs in phobos because there's
essentially no agreement about what cross-platform library is standard.


Python has something and as far as I can tell people are fine with that.

Andrei

Re: What does C++ do better than D? - StackOverflow.com

[Jonathan M Davis]

On Monday 01 August 2011 21:28:51 Andrei Alexandrescu wrote:
> On 8/1/11 9:09 PM, bearophile wrote:
> > Andrei:
> >> Mentioning these to the outside blows the issues out of proportion
> >> and conveys the wrong message to someone coming anew to D.
> > 
> > This is often true, unfortunately. But doing the opposite too has
> > risks. If you keep saying only good things about a very complex
> > systems X, people naturally start getting suspicious, because simply
> > a so much complex system can't be perfect.
> 
> I didn't advocate the opposite, and I don't think my response on SE was
> only discussing the shiny city on the hill.

Though I was pretty much accused of that in the reddit thread. :)

- Jonathan M Davis

Re: What library functionality would you most like to see in D?

[Brad Roberts]

On Monday, August 01, 2011 7:31:13 PM, Andrei Alexandrescu wrote:
> On 8/1/11 7:51 PM, Brad Roberts wrote:
>>
>> I don't think that any gui library belongs in phobos because there's
>> essentially no agreement about what cross-platform library is standard.
> 
> Python has something and as far as I can tell people are fine with that.
> 
> Andrei

It has something _in the base library_?  It has wrappers for all/most 
of the popular libraries?  The standard distributions install some 
combination of those?

I don't use python so I'm ill equipped to discuss, but my guess is that 
it's not the first but rather the last.

Re: What library functionality would you most like to see in D?

[Adam D. Ruppe]

I've been thinking about a minimalist drawing library for
phobos - just basic 2d stuff, but with easy enough hooks to
add more (native api events and handles.

Nobody is likely to agree on a widget set, but basic drawing
functions give a little usability with pretty small cost.

I had a decent start a month or two ago but have since stalled out
as my schedule became more ridiculous.

Re: What does C++ do better than D? - StackOverflow.com

[Adam D. Ruppe]

Andrei Alexandrescu wrote:
> I know how to fix the design (in fact the implementation, the
> design is sound). It's just ever so difficult to find the time to
> prioritize for it.

What direction were you going? If it's a brief enough writeup I
might be able to see where you were going and write the code myself.

(I'm starting to get a feel for github too so I can to the whole
pull request route!)

Re: pi benchmark on ldc and dmd

[Adam D. Ruppe]

bearophile wrote:
> Do you mean code similar to this one, or code that uses std.bigint?

It was something that used bigint. I whipped it up myself earlier
this morning, but left the code on my laptop. I'll post it when
I have a chance.

I ran obj2asm on it myself, but was a little short on time, so
I haven't really analyzed it yet.

Re: What library functionality would you most like to see in D?

[bearophile]

Andrei Alexandrescu:

Brad Roberts:
> > I don't think that any gui library belongs in phobos because there's
> > essentially no agreement about what cross-platform library is standard.
> 
> Python has something and as far as I can tell people are fine with that.

The situation is quite complex, some notes:
- CPython indeed has a GUI toolkit in the standard distribution, it's not 
native, it's a whole different interpreter with its GUI toolkit (Tcl-Tk), with 
a thin Python wrapper around it (tkinter). Despite looking like a card castle 
this somehow works and some people (like me) use this GUI toolkit to write 
simple GUIs. Scientific programs sometimes enjoy such simple GUIs.
- For a lot of time the GUIs created with tkinter didn't look native at all 
(the GUI were almost ugly (recently Tk has improved a lot on this, now it looks 
much more native)). And Tk despite having some qualities (efficiency, 
compactness, flexibility and more), was also limited and "strange" in its usage 
(it's like working with soft rubber). So people that want to create serious 
GUIs for Python programs never use tkinter. They use GTK, Wx and lately Qt. So 
using Python as comparison point for D GUI toolkits in the std library is not 
the best thing to do, because in a sense the Python std library GUI toolkit is 
not used by serious people.
- I like the idea of having a wide D standard library. But GUI toolkits are 
large, and they change a lot with time, so I accept to have them as external 
libraries.
- Delphi has a good enough built-in GUI toolkit, and people use it a lot. I 
have used it plenty. This seems a better comparison point for D.
- I'd like a simple graphics module in Phobos, to show simple graphics. It's 
handy in many situations, and it's useful to establish *standard D-wide* 
method/function names to plot a point, a line, circle, box, ecc. The same names 
can later appear in non-Phobos GUI toolkits.
- I'd also like a std.image module to load and save images in png, gif, jpeg, 
ppm, bmp. This is a very common need, even more common than a GUI toolkit, and 
there are far less ways to load a PNG than to create the API of a GUI toolkit.

Bye,
bearophile

Re: pi benchmark on ldc and dmd

[bearophile]

Adam D. Ruppe:
 
> It was something that used bigint. I whipped it up myself earlier
> this morning, but left the code on my laptop. I'll post it when
> I have a chance.

OK.
In such situations it's never enough to compare the D code compiled with DMD to 
the D code compiled with LDC. You also need a reference point, like a C version 
compiled with GCC (here using GMP bignums). Such reference points are necessary 
to anchor performance discussions to something.

Bye,
bearophile

Re: pi benchmark on ldc and dmd

[Adam D. Ruppe]

bearophile wrote:
> In such situations it's never enough to compare the D code compiled
> with DMD to the D code compiled with LDC. You also need a reference
> point, like a C version compiled with GCC (here using GMP bignums).
> Such reference points are necessary to anchor performance
> discussions to something.

Actually, I don't think that would be relevant here.

The thread started with someone saying the DMD backend is garbage
and should be abandoned.

I'm sick and tired of hearing people say that. The Digital Mars
code has many, many advantages over the others*.

But, it was challenged specifically on the optimizer, so to
check that out, I wanted all other things to be equal.

Same code, same front end, same computer, as close to same runtime
and library is possible with different compilers. The only
difference should be the backend so we can draw conclusions about
it without other factors skewing the results.


So for this, I just wanted to compare dmd backend to ldc and
gdc backend so I didn't worry too much about absolute numbers
or other languages. (Actually, one of the reasons I picked the
pi one was after the embarrassing defeat in floating point, I was
hoping dmd could score a second victory and I could follow up
on that "prove it" post with satisfaction. Alas, the facts didn't
work out that way. Though, I still do find dmd to beat g++
on a lot of real world code - things like slices actually make
a sizable difference.)

But regardless, it was just about comparing backends, not
doing language comparisons.

===

* To name a huge one. Today was the first time I ever got ldc
or gdc to actually work on my computer, and it took a long, long
time to do it. I've tried in the past, and failed, so this was
a triumph. Big success.

I was waiting over an hour just for gcc+gdc to compile! In the
time it takes for gcc's configure script to run, you can make
clean, build dmd, druntime and phobos.

It's a huge hassle to get the code together too. I had to go
to *four* different sites to get gdc's stuff together (like 80
MB of crap, compressed!), and two different ones to get even the
ldc binary to work. Pain in my ASS.


And this is on Linux too. I pity the fool who tries to do this
on Windows, knowing how so much linux software treats their
Windows "ports".


I'd like to contrast to dmd: unzip and play with wild abandon.

Re: Still cannot build Phobos from git

[Andre Tampubolon]

On 27-Jul-11 10:23 PM, Dmitry Olshansky wrote:
> My recipe on Windows:
> 1. Get the latest release zip you can find, unzip to some drive root(!
> otherwise get's trickier)
> 2. Delete all within src subfolder
> 3. Get a Git console in \dmd2\src, then the usual:
> git clone https://github.com/D-Programming-Language/dmd.git
> git clone https://github.com/D-Programming-Language/druntime.git
> git clone https://github.com/D-Programming-Language/phobos.git
> 4. Build dmd
> cd dmd\src
> make -f win32.mak release
> copy dmd.exe ..\..\..\windows\bin
> cd ..
> (to build dmd you'd need DMC, also extracted to the same drive root)
> 5.
> cd druntime
> make -f win32.mak
> 
> 6.
> cd phobos
> make -f win32.mak unittest
> copy phobos.lib ..\..\windows\lib
> 
> If anywhere of the above it fails to find dmd, make sure
> dmd2\windows\bin is in your path.
> That's it, no additional tweaking required.
> 

On the PC I'm working now, there were no git installed, so I decided to
grab the latest tarballs:
D-Programming-Language-dmd-v2.054-211-g1dac08b.tar.gz
D-Programming-Language-druntime-v2.054-28-gd14a1a9.tar.gz
D-Programming-Language-phobos-v2.054-119-gcd5d266.tar.gz

Anyway, these were what I did:
1. Extracted the latest release (dmd.2.054.zip) to C:\dmd2-dev. There
were also C:\dmd2, and C:\dm (the Digital Mars C compiler).

2. set PATH=C:\dm\bin

3. cd C:\dmd2-dev\src\dmd.

4. Verified whether DMC worked properly or not, by building DMD:
make -f win32.mak release

The output was:

...
...

make -fwin32.mak C=backend TK=tk ROOT=root clean
del *.obj
del total.sym
del msgs.h msgs.c
del elxxx.c cdxxx.c optab.c debtab.c fltables.c tytab.c
del impcnvtab.c

It was a success.

5. Deleted all the contents of C:\dmd2-dev\src\dmd, and replaced it with
the latest version (from the tarball), and build it again:
\dm\bin\dmc -c -Ibackend;tk -DMARS -cpp  -e -wx -I. backend\var

\dm\bin\dmc -c -Ibackend;tk -DMARS -cpp  -e -wx backend\el

\dm\bin\dmc -c -Ibackend;tk -DMARS -cpp  -e -wx backend\newman
Fatal error: unable to open input file 'parser.h'
--- errorlevel 1

Hmm unable to open parser.h?
I checked C:\dmd2-dev\src\dmd\backend. Yep, no parser.h there (someone
forgot to commit it)?
So I cleared C:\dmd2-dev\src\dmd\ again. First extracted the original
one from the latest release (2.054), then replaced it with the latest
from git, and built it again:
\dm\bin\dmc -c -Ibackend;tk -DMARS -cpp  -e -wx -I. backend\var

\dm\bin\dmc -c -Ibackend;tk -DMARS -cpp  -e -wx backend\el

\dm\bin\dmc -c -Ibackend;tk -DMARS -cpp  -e -wx backend\newman
void
   ^
backend\parser.h(215) : Error: ';' expected following declaration of
struct member
--- errorlevel 1

At least the error was different. I did a quick glance on
C:\dmd2-dev\src\dmd\backend\parser.h around line 215, and found these
lines:

TARGET_structBLKLST

void print();

What is this TARGET_structBLKLST?

-- 
- Andre Tampubolon -

Re: pi benchmark on ldc and dmd

[Andrew Wiley]

On Mon, Aug 1, 2011 at 8:38 PM, Adam D. Ruppe wrote:

> bearophile wrote:
> > In such situations it's never enough to compare the D code compiled
> > with DMD to the D code compiled with LDC. You also need a reference
> > point, like a C version compiled with GCC (here using GMP bignums).
> > Such reference points are necessary to anchor performance
> > discussions to something.
>
> Actually, I don't think that would be relevant here.
>
> The thread started with someone saying the DMD backend is garbage
> and should be abandoned.
>
> I'm sick and tired of hearing people say that. The Digital Mars
> code has many, many advantages over the others*.
>
> But, it was challenged specifically on the optimizer, so to
> check that out, I wanted all other things to be equal.
>
> Same code, same front end, same computer, as close to same runtime
> and library is possible with different compilers. The only
> difference should be the backend so we can draw conclusions about
> it without other factors skewing the results.
>
>
> So for this, I just wanted to compare dmd backend to ldc and
> gdc backend so I didn't worry too much about absolute numbers
> or other languages. (Actually, one of the reasons I picked the
> pi one was after the embarrassing defeat in floating point, I was
> hoping dmd could score a second victory and I could follow up
> on that "prove it" post with satisfaction. Alas, the facts didn't
> work out that way. Though, I still do find dmd to beat g++
> on a lot of real world code - things like slices actually make
> a sizable difference.)
>
> But regardless, it was just about comparing backends, not
> doing language comparisons.
>
> ===
>
> * To name a huge one. Today was the first time I ever got ldc
> or gdc to actually work on my computer, and it took a long, long
> time to do it. I've tried in the past, and failed, so this was
> a triumph. Big success.
>
> I was waiting over an hour just for gcc+gdc to compile! In the
> time it takes for gcc's configure script to run, you can make
> clean, build dmd, druntime and phobos.
>
> It's a huge hassle to get the code together too. I had to go
> to *four* different sites to get gdc's stuff together (like 80
> MB of crap, compressed!), and two different ones to get even the
> ldc binary to work. Pain in my ASS.
>
>
> And this is on Linux too. I pity the fool who tries to do this
> on Windows, knowing how so much linux software treats their
> Windows "ports".
>
>
> I'd like to contrast to dmd: unzip and play with wild abandon.
>

Yes, GDC takes forever and a half to build. That's true of anything in GCC,
and it's just because they don't trust the native C compiler at all. LDC
builds in under a half hour, even on my underpowered ARM SoC, so I don't see
how you could be having trouble there.
As for Windows, Daniel Green (hopefully I'm remembering right) has been
posting GDC binaries.

I do respect that DMD generates reasonably fast executables recklessly fast,
but it also doesn't exist outside x86 and x86_64 and the debug symbols (at
least on Linux) are just hilariously bad.

Now if I could just get GDC to pad structs correctly on ARM...

Re: std.path review: second update

[Jesse Phillips]

On Mon, 01 Aug 2011 20:50:21 +, Jonathan M Davis wrote:

st my pragmatic, Windows-sentric view of things :)
> 
> The problem with that is that then you _can't_ have something like
> "foo..bar". Granted, that's not a normal thing to do, but it would be
> problematic if it ever happened.

You can, you just wouldn't build it with these functions. And frankly if 
you are using these then you probably wouldn't want foo..bar and wouldn't 
care that it ended up foo.bar or foo..bar. You just want the proper 
extension on the proper name, which is what you'd get.
 
> The primary danger I see with using null for no extension and empty for
> "." is
> 
> assert(extension("file.") == extension("file"));
> 
> That could cause problems for any program that actually runs into a file
> which ends with a ".". Now, if Linux, Windows, and Mac OS X all prevent
> files ending in a dot (which I seriously doubt), then it isn't really an
> issue. Having the difference between null and empty does make it
> possible to distinguish if you start doing stuff like

I disagree, that assertion should pass. They both have the same 
extension. If you really want to know if a file name ends in a dot,

assert("file."[$-1] == ".");

I just don't see a case where you'd be dealing with these too files and 
care to know the extension is explicitly empty or umm just empty.

Re: What should be reterned by std.array.replaceFirst

[Jesse Phillips]

On Sat, 30 Jul 2011 07:29:54 +0800, zhang wrote:

> I tested std.array.replaceFirst with the code belown:
> 
> string s1 = "abc bcf";
> 
> string s2 = s1.replaceFirst("bc", "ee"); writefln("%s\n%s", s1, s2);
> 
> and got s2 is "aee". Should it be "aee bcf"?
> 
> Is it a bug, or just it is that?
> 
> Thanks.
> --
> Zhang 

I'd say, bug file it.

http://d.puremagic.com/issues/

Re: std.path review: second update

[Jonathan M Davis]

On Tuesday 02 August 2011 05:41:11 Jesse Phillips wrote:
> On Mon, 01 Aug 2011 20:50:21 +, Jonathan M Davis wrote:
> 
> st my pragmatic, Windows-sentric view of things :)
> 
> > The problem with that is that then you _can't_ have something like
> > "foo..bar". Granted, that's not a normal thing to do, but it would be
> > problematic if it ever happened.
> 
> You can, you just wouldn't build it with these functions. And frankly if
> you are using these then you probably wouldn't want foo..bar and wouldn't
> care that it ended up foo.bar or foo..bar. You just want the proper
> extension on the proper name, which is what you'd get.
> 
> > The primary danger I see with using null for no extension and empty for
> > "." is
> > 
> > assert(extension("file.") == extension("file"));
> > 
> > That could cause problems for any program that actually runs into a file
> > which ends with a ".". Now, if Linux, Windows, and Mac OS X all prevent
> > files ending in a dot (which I seriously doubt), then it isn't really an
> > issue. Having the difference between null and empty does make it
> > possible to distinguish if you start doing stuff like
> 
> I disagree, that assertion should pass. They both have the same
> extension. If you really want to know if a file name ends in a dot,
> 
> assert("file."[$-1] == ".");
> 
> I just don't see a case where you'd be dealing with these too files and
> care to know the extension is explicitly empty or umm just empty.

The main issue that I see is that it becomes too easy to have a program think 
that the names of two files are identical if you're dealing with their pieces 
instead of their whole. Granted, this is not exactly a normal situation, but 
I'd much prefer to have it handled cleanly so that programs that get into such 
a situation don't end up being buggy rather than declaring that two items 
which aren't identical as being equal.

- Jonathan M Davis

Re: std.path review: second update

[Jonathan M Davis]

On Monday 01 August 2011 22:55:02 Jonathan M Davis wrote:
> On Tuesday 02 August 2011 05:41:11 Jesse Phillips wrote:
> > On Mon, 01 Aug 2011 20:50:21 +, Jonathan M Davis wrote:
> > 
> > st my pragmatic, Windows-sentric view of things :)
> > 
> > > The problem with that is that then you _can't_ have something like
> > > "foo..bar". Granted, that's not a normal thing to do, but it would
> > > be
> > > problematic if it ever happened.
> > 
> > You can, you just wouldn't build it with these functions. And frankly if
> > you are using these then you probably wouldn't want foo..bar and
> > wouldn't
> > care that it ended up foo.bar or foo..bar. You just want the proper
> > extension on the proper name, which is what you'd get.
> > 
> > > The primary danger I see with using null for no extension and empty
> > > for
> > > "." is
> > > 
> > > assert(extension("file.") == extension("file"));
> > > 
> > > That could cause problems for any program that actually runs into a
> > > file which ends with a ".". Now, if Linux, Windows, and Mac OS X
> > > all prevent files ending in a dot (which I seriously doubt), then
> > > it isn't really an issue. Having the difference between null and
> > > empty does make it possible to distinguish if you start doing stuff
> > > like
> > 
> > I disagree, that assertion should pass. They both have the same
> > extension. If you really want to know if a file name ends in a dot,
> > 
> > assert("file."[$-1] == ".");
> > 
> > I just don't see a case where you'd be dealing with these too files and
> > care to know the extension is explicitly empty or umm just empty.
> 
> The main issue that I see is that it becomes too easy to have a program
> think that the names of two files are identical if you're dealing with
> their pieces instead of their whole. Granted, this is not exactly a normal
> situation, but I'd much prefer to have it handled cleanly so that programs
> that get into such a situation don't end up being buggy rather than
> declaring that two items which aren't identical as being equal.

Actually, I suppose that I could sum up my take on it by saying that if the 
two aren't absolutely identical, they shouldn't be treated as equal.

"file." and "file" do _not_ have the same extension. One has an empty extension 
whereas the other has none. Most stuff won't care about the difference, in 
which 
case it probably won't care whether extension("file.") == extension("file") or 
not (in fact, all it probably care about is whether the extension is a 
particular extension or not). But stuff which _does_ care about the difference 
_will_ care whether extension("file.") == extension("file"). It _won't_ want 
them to be equal.

In general, I don't like the idea of null and empty being conflated - they're 
two separate things. It's bad enough that arrays act that way in D. There's no 
need to propagate it to file extensions as well.

- Jonathan M Davis

Re: What library functionality would you most like to see in D?

[Marco Leise]

Am 02.08.2011, 04:48 Uhr, schrieb Adam D. Ruppe  
:



I've been thinking about a minimalist drawing library for
phobos - just basic 2d stuff, but with easy enough hooks to
add more (native api events and handles.

Nobody is likely to agree on a widget set, but basic drawing
functions give a little usability with pretty small cost.

I had a decent start a month or two ago but have since stalled out
as my schedule became more ridiculous.


I used a few drawing APIs: Delphi/Win32, Java2D, HTML5 Canvas, Gtk+ and  
recently Cairo. If there was a drawing API in Phobos I wish it was like  
Cairo. While some basic APIs have some special ability (like shadows in  
the HTML canvas) they often lack some essential functions. Java2D offers a  
lot, but I consider it bloated, YMMW. When I was writing a tool I came to  
need more and more advanced features:

- fonts and text drawing
- clipping
- scaling (part of matrix manipulation)
- transparency
- measuring of the extents of what is about to be drawn
I was using GtkD, the D wrapper for Gtk and Gtk lacked a lot of this.  
Fortunately Gtk comes with Cairo bindings which offered all that. This is  
just one example and just me, but I really think Cairo's API is very well  
designed, similar to Java2D and HTML5 Canvas and would be my reference for  
a drawing API in D. It doesn't need to offer bezier curves and  
anti-aliasing in the first version, but the idea of filling and stroking  
shapes or drawing surfaces that can be rendered into each other are kind  
of a standard now that can be built upon :)


- Marco