Re: MinPSPW supports D
On 2010-10-29 07:12, Nick Sabalausky wrote: Denis Koroskin2kor...@gmail.com wrote in message news:op.vlbmgmt2o7c...@korden-pc... On Fri, 29 Oct 2010 08:03:17 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Found this with google alert: http://dogoautilio.wordpress.com/2010/10/28/minpspw-0-9-10-is-out/ Andrei I used D to code for my PSP almost two years ago with these tools (GDC/D1): http://forums.qj.net/psp-development-forum/142864-how-program-d-psptoolchain-gdc.html About three and a half years ago another guy and I got GDC/D1 working (...sort of...) on GameBoy Advance: https://www.semitwist.com/articles/article/view/d-on-gba-nds-progress-thanks-to-oopman The downside is there was abolutely no phobos/tango/druntime whatsoever, so a bunch of language features like structs and classes were unusable. But I got a trivial sample app running. Didn't structs work? I would guess that what would be one of the thinks that should work. D is perfect for these sorts of systems. It's been years since I've actually had any time for homebrew, but back when I did I would have loved to have been able to use a fully-functional D (even if it was sans-GC) instead of dealing with the ancient C. -- /Jacob Carlborg
Re: QtD is resumed
Max Samukha Wrote: As there is interest in the project, we have decided to proceed. Stay tuned. Perhaps someone could update the website to mention that the project is still active? http://www.dsource.org/projects/qtd
dmd 1.065 and 2.050 release
This is primarily a bug fix release. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.065.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.050.zip
Re: dmd 1.065 and 2.050 release
Walter Bright wrote: This is primarily a bug fix release. And relaxed purity rules. They rule!
Re: dmd 1.065 and 2.050 release
Lutger lutger.blijdest...@gmail.com wrote in message news:iaf5bc$1ro...@digitalmars.com... Walter Bright wrote: This is primarily a bug fix release. And relaxed purity rules. They rule! Ha! I see what you did there... ;)
Re: dmd 1.065 and 2.050 release
Walter Bright newshou...@digitalmars.com wrote in message news:iaf0mo$1js...@digitalmars.com... This is primarily a bug fix release. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.065.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.050.zip Not a big deal, but there's a 32-byte file named .exe in windows/bin.
Re: dmd 1.065 and 2.050 release
Thank you and the other people for the release.
--
From the changelog:
added talign() and argTypes() to TypeInfo
But in this page I am seeing info only about talign():
http://www.digitalmars.com/d/2.0/phobos/object.html#talign
size_t talign(); Return alignment of type
What is argTypes()? Is it explained elsewhere in the docs?
--
Bugzilla 4987: C function pointer syntax needs to be deprecated
The situation for this bug is unchanged:
http://d.puremagic.com/issues/show_bug.cgi?id=4530
-
Added relaxed purity checking rules.
Very good. I hope Phobos will be updated to use that improvement, examples:
http://d.puremagic.com/issues/show_bug.cgi?id=5121
http://d.puremagic.com/issues/show_bug.cgi?id=5124
-
Bugzilla 2310: Inconsistent formatting of arrays in std.stdio.write() and
std.conv.to!(string)()
Good. But it's silly that two so different arrays have the same textual
representation:
import std.stdio;
void main() {
auto a = [1, 2, 3];
auto b = [1, 2, 3];
writeln(a); // prints [1, 2, 3]
writeln(b); // prints [1, 2, 3]
}
For the first array a textual representation like this is better because you
can tell apart strings and integers from the printout:
[1, 2, 3]
This problem is the one that originally made me start putting bug reports in
Bugzilla, it's my the first bug report and I regard it as important enough:
http://d.puremagic.com/issues/show_bug.cgi?id=3813
Bye,
bearophile
Re: Lints, Condate and bugs
On 10/28/2010 1:40 PM, Walter Bright wrote:
Don wrote:
With the bugs I've fixed in the DMD source, I've seen very many cases
of 7, several cases of 2 and 6, and only one case of 8.
Many bugs are also caused by dangerous casts (where a pointer is cast
from one type to another).
But almost everything else been caused by a logic error.
I am certain that there are still many null pointer bugs in DMD.
None of the null pointer bugs dmd has had would have been prevented by
using non-nullable types. I.e. they were not I forgot to initialize
this pointer, but were instead the result of logic errors, like running
off the end of a list.
Preventing bad initializations at compile time is not the only benefit
of non-nullable types worth considering.
They would be a great help in debugging programs, for example.
NullPointerException is probably the most common error I see in Java.
95% of all times it gets thrown in some weird context, which gives you
no idea about what happened. The result is a long and tedious debugging
session.
Here is a common case:
String name = Config.get(name); //returns null, no error
//...
if (name.length() 0) { //NullPointerException!
The problem is that the second line could be reached after executing
hundreds of lines of (unrelated) code. The null could be passed around,
propagated through method calls. The exception could even be thrown from
a deeply nested call in a third party library. Stuff like that is common
and really difficult to debug.
With non-nullable types, the exception will be thrown on the first line
(where assignment happens), making it obvious, which piece of code is at
fault and potentially saving hours of programmer's time.
Another benefit of non-nullable types is that they can serve as a form
of documentation, making intent behind the code clearer, and making the
code easier to read:
Old Java:
if (myString != null !myString.equals())
C#:
if (!String.IsNullOrEmpty(myString))
Could be:
if (myString != )
NULL in dmd represents this datum has not been computed yet or this
datum has an invalid value or this datum does not exist. With
non-nullable types, they'd have to be set to a datum that asserts
whenever it is accessed, leading to the same behavior.
Having the program abort due to an assert failure rather than a segment
violation is not the great advance it's sold as. I think one should
carefully consider whether a particular null pointer problem is a
symptom of a logic bug or not before claiming that eliminating null
pointers will magically resolve it.
Otherwise, you're just shooting the messenger.
Re: Lints, Condate and bugs
Am 29.10.2010 09:26, schrieb Roman Ivanov: They would be a great help in debugging programs, for example. NullPointerException is probably the most common error I see in Java. 95% of all times it gets thrown in some weird context, which gives you no idea about what happened. The result is a long and tedious debugging session. 100% correct - but to have null-able types help to writer code faster in the prototype phase, and not having them will also change the way developers are forced to write code and there are million developers out there who likes/and use null-able values for flow-control - if the null-able feature is removed without something that keeps the style working, you will loose them, or much more evil, they will try to code around the non-null-able-style getting back to there well known null-able behavior, by using bools, ints, strings whatever - that will not help in library growth around D try comming up with an pattern that keeps both pro/cons...
Re: Lints, Condate and bugs
On Fri, 29 Oct 2010 11:58:56 +0400, dennis luehring dl.so...@gmx.net
wrote:
Am 29.10.2010 09:26, schrieb Roman Ivanov:
They would be a great help in debugging programs, for example.
NullPointerException is probably the most common error I see in Java.
95% of all times it gets thrown in some weird context, which gives you
no idea about what happened. The result is a long and tedious debugging
session.
100% correct - but to have null-able types help to writer code faster in
the prototype phase, and not having them will also change the way
developers are forced to write code
and there are million developers out there who likes/and use null-able
values for flow-control - if the null-able feature is removed without
something that keeps the style working, you will loose them, or much
more evil, they will try to code around the non-null-able-style getting
back to there well known null-able behavior, by using bools, ints,
strings whatever - that will not help in library growth around D
try comming up with an pattern that keeps both pro/cons...
No one is talking about removing nullable references but rather adding
non-nullable types and making them default. You could still achieve old
behavior if it is needed (most proposed proposed syntax):
Foo? foo = stuff.find(predicate);
if (foo is null) {
// not found
}
Re: Lints, Condate and bugs
Am 29.10.2010 11:07, schrieb Denis Koroskin:
On Fri, 29 Oct 2010 11:58:56 +0400, dennis luehringdl.so...@gmx.net
wrote:
Am 29.10.2010 09:26, schrieb Roman Ivanov:
They would be a great help in debugging programs, for example.
NullPointerException is probably the most common error I see in Java.
95% of all times it gets thrown in some weird context, which gives you
no idea about what happened. The result is a long and tedious debugging
session.
100% correct - but to have null-able types help to writer code faster in
the prototype phase, and not having them will also change the way
developers are forced to write code
and there are million developers out there who likes/and use null-able
values for flow-control - if the null-able feature is removed without
something that keeps the style working, you will loose them, or much
more evil, they will try to code around the non-null-able-style getting
back to there well known null-able behavior, by using bools, ints,
strings whatever - that will not help in library growth around D
try comming up with an pattern that keeps both pro/cons...
No one is talking about removing nullable references but rather adding
non-nullable types and making them default. You could still achieve old
behavior if it is needed (most proposed proposed syntax):
Foo? foo = stuff.find(predicate);
if (foo is null) {
// not found
}
No one is talking about removing nullable references
sorry
most proposed proposed syntax
like it works in C# - but better because of ...and making them default. :)
sound very similar to the long talked about make parameters const per
default proposal - which is also still not there :(
Re: Language Popularity
On 10/28/2010 04:45 PM, Jérôme M. Berger wrote: Todd VanderVeen wrote: http://langpop.com/ Interesting that D comes first on Reddit with a reasonably comfortable margin ;) It's how they performed the search. These stats are pure crap, because D matches tons of miscellaneous stuff. There's no way D is more popular than Python on reddit. I remember years back when the D community was so obsessed over it's Tiobe number, watching every little movement, and those stats were complete crap too.
Re: Lints, Condate and bugs
On Friday 29 October 2010 03:06:56 dennis luehring wrote:
Am 29.10.2010 11:07, schrieb Denis Koroskin:
On Fri, 29 Oct 2010 11:58:56 +0400, dennis luehringdl.so...@gmx.net
No one is talking about removing nullable references but rather adding
non-nullable types and making them default. You could still achieve old
behavior if it is needed (most proposed proposed syntax):
Foo? foo = stuff.find(predicate);
if (foo is null) {
// not found
}
No one is talking about removing nullable references
sorry
most proposed proposed syntax
like it works in C# - but better because of ...and making them default.
:)
sound very similar to the long talked about make parameters const per
default proposal - which is also still not there :(
Personally, I think that both would be horrible. Having const is great, and
having non-nullable references could be great, but I sure wouldn't want them to
be the default. In addition to that, however, having them as the default would
make porting code from other C-based languages a total nightmare - not to
mention it totally shatters the general principle that either C/C++ code is
valid D code with the exact same behavior it doesn't compile. That alone makes
making them the default untenable.
- Jonathan M Davis
Re: Language Popularity
On Friday 29 October 2010 03:49:32 Jeff Nowakowski wrote: On 10/28/2010 04:45 PM, Jérôme M. Berger wrote: Todd VanderVeen wrote: http://langpop.com/ Interesting that D comes first on Reddit with a reasonably comfortable margin ;) It's how they performed the search. These stats are pure crap, because D matches tons of miscellaneous stuff. There's no way D is more popular than Python on reddit. I remember years back when the D community was so obsessed over it's Tiobe number, watching every little movement, and those stats were complete crap too. It's the sort of thing which is indicative of how much a language is discussed or used but which isn't accurate to base much off of. The fact that Java is near the top of most such lists whereas D is near the bottom definitely means something - Java is definitely used more than D. However, whether D is used more than Haskell or Erlang or any other language that might be near it on such lists means a lot less. And, of course, as you point out, D is a terrible name for a language from the standpoint of keyword searches, which doesn't help at all. So, I wouldn't say that such lists are worth nothing, but you have to take them with a large grain of salt. - Jonathan M Davis
Re: Simulating Multiple Inheritance
Jonathan M Davis Wrote: On Thursday, October 28, 2010 15:46:23 Jesse Phillips wrote: Jimmy Cao Wrote: Well, you can't have multiple alias this's right? So then, wouldn't it still only limit to 2 base classes? Well, you can't have multiple alias this's right?divbr/divdivSo then, wouldn't it still only limit to 2 base classes?/div This is an issue with the implementation, the language allows for as many alias this as you wish. Yeah. TDPL specifically says that you can have multiple alias this's (in the section on this exact topic too, IIRC), so it's on the list of things that TDPL says and D that dmd hasn't correctly implemented yet. So no D2 staple for me ? When is ready? TDLP not high priority?
Re: Proposal: Relax rules for 'pure'
Robert Jacques Wrote: Getting back to pure, one of the big advantages of functional languages are their ability to automatically parallelize themselves; and they use a work stealing runtime (aka tasks) to do this. What functional has task? I switch in Meantime when D2 not staple to study this.
Re: Lints, Condate and bugs
dennis luehring Wrote: Am 29.10.2010 09:26, schrieb Roman Ivanov: They would be a great help in debugging programs, for example. NullPointerException is probably the most common error I see in Java. 95% of all times it gets thrown in some weird context, which gives you no idea about what happened. The result is a long and tedious debugging session. 100% correct - but to have null-able types help to writer code faster in the prototype phase, and not having them will also change the way developers are forced to write code and there are million developers out there who likes/and use null-able values for flow-control - if the null-able feature is removed without something that keeps the style working, you will loose them, or much more evil, they will try to code around the non-null-able-style getting back to there well known null-able behavior, by using bools, ints, strings whatever - that will not help in library growth around D try comming up with an pattern that keeps both pro/cons... I need null whole time. Null = empty array. Null = empty object. Null = 0 integer. Null = 0 floating point. Null = String with length 0. Null = void return in function. It so good many places. Not have null make me not know how to program! then I switch to C++!
Re: Streaming library (NG Threading)
On 13/10/2010 18:48, Daniel Gibson wrote: Andrei Alexandrescu schrieb: On 10/13/10 11:16 CDT, Denis Koroskin wrote: P.S. For threads this deep it's better fork a new one, especially when changing the subject. I thought I did by changing the title... Andrei At least on my Thunderbird/Icedove 2.0.0.24 it's still in the old Thread. Same here on my Thunderbird 3.0. Is seems TB cares more about the References: field in NNTP message to determine the parent. In fact, with version 3 of TB, it seems that's all it considers... which means that NG messages with the same title as the parent will not be put in the same thread as the parent if they don't have the references field. That sounds like the right approach, however there are some problems in practice because some clients never put the references field (particularly Webnews I think), so all those messages show up in my TB as new threads. :/ -- Bruno Medeiros - Software Engineer
Re: Lints, Condate and bugs
dennis luehring Wrote:
Am 29.10.2010 11:07, schrieb Denis Koroskin:
On Fri, 29 Oct 2010 11:58:56 +0400, dennis luehringdl.so...@gmx.net
wrote:
Am 29.10.2010 09:26, schrieb Roman Ivanov:
They would be a great help in debugging programs, for example.
NullPointerException is probably the most common error I see in Java.
95% of all times it gets thrown in some weird context, which gives you
no idea about what happened. The result is a long and tedious debugging
session.
100% correct - but to have null-able types help to writer code faster in
the prototype phase, and not having them will also change the way
developers are forced to write code
and there are million developers out there who likes/and use null-able
values for flow-control - if the null-able feature is removed without
something that keeps the style working, you will loose them, or much
more evil, they will try to code around the non-null-able-style getting
back to there well known null-able behavior, by using bools, ints,
strings whatever - that will not help in library growth around D
try comming up with an pattern that keeps both pro/cons...
No one is talking about removing nullable references but rather adding
non-nullable types and making them default. You could still achieve old
behavior if it is needed (most proposed proposed syntax):
Foo? foo = stuff.find(predicate);
if (foo is null) {
// not found
}
No one is talking about removing nullable references
sorry
most proposed proposed syntax
like it works in C# - but better because of ...and making them default. :)
sound very similar to the long talked about make parameters const per
default proposal - which is also still not there :(
const parameters no good per default. I reuse parameters whole time to space
conservations. Imagine if browser need twice space for all functions, make them
too big. Already needs 2 GigaB of my 4 GigaB system. We need fight bloat with
every weapons. They fix this bug:
this(int x, int y) {
x = x;
this.y = y;
}
but only bad coder make mistakes. D programmers old C++ veterans so make no
mistakes ever.
Re: Streaming library (NG Threading)
On Fri, 29 Oct 2010 15:40:35 +0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 13/10/2010 18:48, Daniel Gibson wrote: Andrei Alexandrescu schrieb: On 10/13/10 11:16 CDT, Denis Koroskin wrote: P.S. For threads this deep it's better fork a new one, especially when changing the subject. I thought I did by changing the title... Andrei At least on my Thunderbird/Icedove 2.0.0.24 it's still in the old Thread. Same here on my Thunderbird 3.0. Is seems TB cares more about the References: field in NNTP message to determine the parent. In fact, with version 3 of TB, it seems that's all it considers... which means that NG messages with the same title as the parent will not be put in the same thread as the parent if they don't have the references field. That sounds like the right approach, however there are some problems in practice because some clients never put the references field (particularly Webnews I think), so all those messages show up in my TB as new threads. :/ Nope, most of the responses through WebNews have correct References in place.
Re: Lints, Condate and bugs
Am 29.10.2010 13:41, schrieb tls:
dennis luehring Wrote:
Am 29.10.2010 11:07, schrieb Denis Koroskin:
On Fri, 29 Oct 2010 11:58:56 +0400, dennis luehringdl.so...@gmx.net
wrote:
Am 29.10.2010 09:26, schrieb Roman Ivanov:
They would be a great help in debugging programs, for example.
NullPointerException is probably the most common error I see in Java.
95% of all times it gets thrown in some weird context, which gives you
no idea about what happened. The result is a long and tedious debugging
session.
100% correct - but to have null-able types help to writer code faster in
the prototype phase, and not having them will also change the way
developers are forced to write code
and there are million developers out there who likes/and use null-able
values for flow-control - if the null-able feature is removed without
something that keeps the style working, you will loose them, or much
more evil, they will try to code around the non-null-able-style getting
back to there well known null-able behavior, by using bools, ints,
strings whatever - that will not help in library growth around D
try comming up with an pattern that keeps both pro/cons...
No one is talking about removing nullable references but rather adding
non-nullable types and making them default. You could still achieve old
behavior if it is needed (most proposed proposed syntax):
Foo? foo = stuff.find(predicate);
if (foo is null) {
// not found
}
No one is talking about removing nullable references
sorry
most proposed proposed syntax
like it works in C# - but better because of ...and making them default. :)
sound very similar to the long talked about make parameters const per
default proposal - which is also still not there :(
const parameters no good per default. I reuse parameters whole time to space
conservations. Imagine if browser need twice space for all functions, make them
too big. Already needs 2 GigaB of my 4 GigaB system. We need fight bloat with
every weapons. They fix this bug:
this(int x, int y) {
x = x;
this.y = y;
}
but only bad coder make mistakes. D programmers old C++ veterans so make no
mistakes ever.
in a library that is not written by you
should be:
void functionX( int refered )
{
refered = 10;
}
was mistakenly types as
void functionX( int refered )
{
refered = 10;
}
now start to find the error in your million lines of code
i've usualy find errors like these in projects im involed in
Re: Lints, Condate and bugs
Jonathan M Davis Wrote:
On Friday 29 October 2010 03:06:56 dennis luehring wrote:
Am 29.10.2010 11:07, schrieb Denis Koroskin:
On Fri, 29 Oct 2010 11:58:56 +0400, dennis luehringdl.so...@gmx.net
No one is talking about removing nullable references but rather adding
non-nullable types and making them default. You could still achieve old
behavior if it is needed (most proposed proposed syntax):
Foo? foo = stuff.find(predicate);
if (foo is null) {
// not found
}
No one is talking about removing nullable references
sorry
most proposed proposed syntax
like it works in C# - but better because of ...and making them default.
:)
sound very similar to the long talked about make parameters const per
default proposal - which is also still not there :(
Personally, I think that both would be horrible. Having const is great, and
having non-nullable references could be great, but I sure wouldn't want them
to
be the default. In addition to that, however, having them as the default
would
make porting code from other C-based languages a total nightmare - not to
mention it totally shatters the general principle that either C/C++ code is
valid D code with the exact same behavior it doesn't compile. That alone
makes
making them the default untenable.
Sometime not having safety is better. You see I write now GUI program for users
uses xview toolkit. xview using kr C
(http://bytes.com/topic/c/answers/215340-k-r-style-function-declarations-good-bad).
I very sad find D not support standard kr C so me consider update dmd
frontend to support kr C. much easy to read:
void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
instead modern confuser sintax.
This show how important support legacy is. Cost many hours writing new dmd
frontend. If also const broken and nulls then this coode won't run at all! No
good. Keep legacy.
Re: Lints, Condate and bugs
Am 29.10.2010 13:36, schrieb tls: dennis luehring Wrote: Am 29.10.2010 09:26, schrieb Roman Ivanov: They would be a great help in debugging programs, for example. NullPointerException is probably the most common error I see in Java. 95% of all times it gets thrown in some weird context, which gives you no idea about what happened. The result is a long and tedious debugging session. 100% correct - but to have null-able types help to writer code faster in the prototype phase, and not having them will also change the way developers are forced to write code and there are million developers out there who likes/and use null-able values for flow-control - if the null-able feature is removed without something that keeps the style working, you will loose them, or much more evil, they will try to code around the non-null-able-style getting back to there well known null-able behavior, by using bools, ints, strings whatever - that will not help in library growth around D try comming up with an pattern that keeps both pro/cons... I need null whole time. Null = empty array. Null = empty object. Null = 0 integer. Null = 0 floating point. Null = String with length 0. Null = void return in function. It so good many places. Not have null make me not know how to program! then I switch to C++! ok you one of these null-using guys - does null also mean time-by-time and error to you ... so what is null in you world? a maybe-no-result, maybe-error or even both
Re: Lints, Condate and bugs
Am 29.10.2010 13:54, schrieb tls:
Jonathan M Davis Wrote:
On Friday 29 October 2010 03:06:56 dennis luehring wrote:
Am 29.10.2010 11:07, schrieb Denis Koroskin:
On Fri, 29 Oct 2010 11:58:56 +0400, dennis luehringdl.so...@gmx.net
No one is talking about removing nullable references but rather adding
non-nullable types and making them default. You could still achieve old
behavior if it is needed (most proposed proposed syntax):
Foo? foo = stuff.find(predicate);
if (foo is null) {
// not found
}
No one is talking about removing nullable references
sorry
most proposed proposed syntax
like it works in C# - but better because of ...and making them default.
:)
sound very similar to the long talked about make parameters const per
default proposal - which is also still not there :(
Personally, I think that both would be horrible. Having const is great, and
having non-nullable references could be great, but I sure wouldn't want them to
be the default. In addition to that, however, having them as the default would
make porting code from other C-based languages a total nightmare - not to
mention it totally shatters the general principle that either C/C++ code is
valid D code with the exact same behavior it doesn't compile. That alone makes
making them the default untenable.
Sometime not having safety is better. You see I write now GUI program for users uses xview
toolkit. xview using kr C
(http://bytes.com/topic/c/answers/215340-k-r-style-function-declarations-good-bad). I very
sad find D not support standard kr C so me consider update dmd frontend to support
kr C. much easy to read:
void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
instead modern confuser sintax.
This show how important support legacy is. Cost many hours writing new dmd
frontend. If also const broken and nulls then this coode won't run at all! No
good. Keep legacy.
sorry but your arguments are loosing any sense, to add KR support only
because of the ease to port an very old style code is nothing more then
stupid 100% ... sorry, but you should not involve yourselfe in language
design dicussion
Re: Streaming library (NG Threading)
On 29/10/2010 12:50, Denis Koroskin wrote: On Fri, 29 Oct 2010 15:40:35 +0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 13/10/2010 18:48, Daniel Gibson wrote: Andrei Alexandrescu schrieb: On 10/13/10 11:16 CDT, Denis Koroskin wrote: P.S. For threads this deep it's better fork a new one, especially when changing the subject. I thought I did by changing the title... Andrei At least on my Thunderbird/Icedove 2.0.0.24 it's still in the old Thread. Same here on my Thunderbird 3.0. Is seems TB cares more about the References: field in NNTP message to determine the parent. In fact, with version 3 of TB, it seems that's all it considers... which means that NG messages with the same title as the parent will not be put in the same thread as the parent if they don't have the references field. That sounds like the right approach, however there are some problems in practice because some clients never put the references field (particularly Webnews I think), so all those messages show up in my TB as new threads. :/ Nope, most of the responses through WebNews have correct References in place. All responses that appear as new threads in my TB (ie, threads whose title starts with Re: ) and for which I have looked at the message source, have user agent: User-Agent: Web-News v.1.6.3 (by Terence Yim) and no references field. These messages are common with some posters, like berophile, Sean Kelly, Kagamin,etc.. But some Web-News messages do have a references field though, so it's not all Web-News messages that are missing it. -- Bruno Medeiros - Software Engineer
Re: Ruling out arbitrary cost copy construction?
On 06/10/2010 17:57, dsimcha wrote: Vote++. IMHO the problem with arbitrary cost copy construction is that abstractions that are this leaky don't actually make people's lives simpler. Abstractions (like value semantics) are supposed to make the code easier to reason about. When an abstraction forces you to think hard about things as trivial as variable assignments, I think it's better to either scrap the abstraction and require all copying to be explicit, or use a less leaky abstraction like reference counting/COW. I agree with this as well. But I'm still wondering if the original copy construction problem couldn't be solved in some other way. -- Bruno Medeiros - Software Engineer
Re: Interfacing to C++
Over time, more aspects of the C++ ABI may be accessible directly from D Anything in sight? Maybe support for namespaces or some other minor thing? Currently, nothing new there. hmm anything else that makes life with D - C++ easier?
Re: Ruling out arbitrary cost copy construction?
On 06/10/2010 17:34, Andrei Alexandrescu wrote: or similar. However, a sealed range does not offer references, so trying e.g. swap(r1.front, r2.front); will not work. This is a problem. Why doesn't a sealed range offer references? Is it to prevent modifying the elements being iterated? (I searched google and TDPL but couldn't find any info on sealed ranges) -- Bruno Medeiros - Software Engineer
Re: On C/C++ undefined behaviours (on the term undefined behaviours)
Note: I've only seen this message now, since I am several threads late in the (date-ordered) queue of unread NG threads, and this message appeared as a new thread. On 06/10/2010 21:00, bearophile wrote: Bruno Medeiros: [...mumble mumble...] I don't like this term undefined behavior [...mumble mumble...] I really don't care about words, and about C, I want signed/unsigned compile-time/run-time overflow errors in D. Bye, bearophile Like I mentioned afterwards, I think communication is important, so we should strive to have a clear understanding of the terms we and other people use. But anyways, regarding this issue, I am satisfied. The D glossary and TDPL have precisely defined undefined behavior, which I didn't know was the case. Also, the related term implementation defined, which some people in the C world equivocate with undefined behavior, has been used here in D, but in also in a more accurate way, distinct from undefined behavior. So that's good. -- Bruno Medeiros - Software Engineer
Re: Ada, SPARK [Was: Re: tolf and detab (language succinctness)]
On 06/10/2010 22:48, bearophile wrote: Bruno Medeiros: [About ADA] That begin endname of block syntax is awful. I already think just begin end syntax is bad, but also having to repeat the name of block/function/procedure/loop at the end, that's awful. If you take a look at my dlibs1, probably more than 60_000 lines of D1 code, you may see that all closing braces of templates, functions, classes, and structs have a comment like: } // end FooBar!() Ada makes sure that comment at the end doesn't get out of sync with the true function mame :-) I agree it's not DRY, but when you aren't using a good IDE that comment helps you understand where you are in the code. Well, I rarely use languages without good IDE's, so... :P But still, even with IDEs aside, I see little use in that kind of information comment. But I try to keep my functions short, both in lines, and depth of nested blocks. And as for aggregate types, of those that have large amount of code, I prefer that there are only a few of them per source file. So this makes it rare that I'm not able to see the whole block in one page. That dlibs1 of yours, is it publicly available somewhere? Let me see your micro... Ada is not designed to write Web applications, it's useful where you need very reliable software, high integrity systems. And in such situations it's very hard to beat it with other languages as C/C++/Java/C#. In such situations a language that helps you avoid bugs is better than a very handy language like Ruby. C language was not designed to write reliable systems, and it shows. D2 language distances itself from C, trying to be (useful to write code) more reliable than C, it uses some of the ideas of Ada (but D2 misses still a basic Ada feature important for highly reliable software systems: optional integral overflows, that in Ada are active on default). I'm not an expert on high-reliability/critical systems, but I had the impression that the majority of it was written in C (even if with restricting code guidelines). Or that at least, much more critical software is written in C than in Ada. Is that not the case? -- Bruno Medeiros - Software Engineer
Re: in everywhere
On 08/10/2010 00:42, Jonathan M Davis wrote: On Thursday, October 07, 2010 16:39:15 Tomek Sowiński wrote: http://en.wikipedia.org/wiki/Halting_problem It's a classic problem in computer science. Essentially what it comes down to is that you can't determine when - or even if - a program will halt until it actually has. It's why stuff like file transfer dialogs can never be totally accurate. And best, you can estimate how long a file transfer will take based on the current progress, but you can't _know_ when it will complete. O_o -- Bruno Medeiros - Software Engineer
Re: Ruling out arbitrary cost copy construction?
On 10/29/10 7:55 CDT, Bruno Medeiros wrote: On 06/10/2010 17:57, dsimcha wrote: Vote++. IMHO the problem with arbitrary cost copy construction is that abstractions that are this leaky don't actually make people's lives simpler. Abstractions (like value semantics) are supposed to make the code easier to reason about. When an abstraction forces you to think hard about things as trivial as variable assignments, I think it's better to either scrap the abstraction and require all copying to be explicit, or use a less leaky abstraction like reference counting/COW. I agree with this as well. But I'm still wondering if the original copy construction problem couldn't be solved in some other way. FWIW this matter is still tormenting me. It gridlocks work on ranges, algorithms, and containers. To recap: 1. Arbitrary cost copy construction: + Makes value types easy to define: just hook the copying code into this(this) + Is familiar to programmers coming from C++ + If it fails, fails early, not surprisingly during a later operation - Creates inefficiencies for innocuous-looking code - Contorts code that wants to be efficient - Makes containers, ranges and other abstractions bulkier and more difficult to define, implement, and use - Forces exposure of raw addresses, which hurt abstraction power and safety 2. Constant-cost copy construction (via mandatory refcounting for value types): + Simplifies life virtually everywhere in client code + Makes code easy to reason about (no hidden inefficiencies, failure paths are more visible) + Makes generic code easier to define and more efficient for many types - Makes value types difficult to define: a value type must store all state and do all manipulation indirectly, via a reference-counted pointer; all methods must check the pointer against null; all mutating methods must use a copy-on-write approach - Needs copy-on-write (COW) approaches in defining object types and COW is error-prone because it relies on the programmer remembering to always ensure a unique copy prior to changing the object - Can become a notable difference from C++ (and consequently a contention point for C++ programmers who are considering migrating to D): arbitrary cost of construction hurts C++ in many places, but it has contained the situation with a combination of complexity, discipline, and acceptance of inefficiencies. Any tie-breaking arguments, I'm all ears. Andrei
Re: Tuple literal syntax + Tuple assignment
On 07/10/2010 19:45, Andrei Alexandrescu wrote: On 10/7/10 12:45 CDT, Michel Fortin wrote: On 2010-10-07 12:34:33 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: My suggestion is that we deprecate TypeTuple and we call it AliasTuple because that's really what it is - it's a tuple of stuff that can be passed in as an alias parameter. Personally, I like D built-in tuples; they're so simple. At the core they're just a group of things. They are terrible, awful, despiteful. They don't compose with anything; you can't have an array of tuples or a hash of tuples. They can't be returned a from a function. They spread their legs in function parameter lists without any control (flattening is bad, right?) Built-in tuples are the pitts. The one thing they're good for is as a back-end for std.typecons.Tuple. In fairness, my impression is they were not meant to compose with anything or be returned with a function. They were created not as a first class type, but as a metaprogramming construct, whose purpose was *exactly* for capturing parameters for templates or functions and expanding them automatically. They were a great boon for D's metaprogramming capabilities. As such they were not meant to emulate tuples as in Python's tuples, or any record type in general. But because they could partially be used as such, and because they share the same name, a lot of comparisons are made, which results in this idea that D's tuples are inferior. This is not saying it would not be useful to have functionality like Python's tuples. -- Bruno Medeiros - Software Engineer
Re: Lints, Condate and bugs
Jonathan M Davis wrote: Personally, I think that both would be horrible. Having const is great, and having non-nullable references could be great, but I sure wouldn't want them to be the default. In addition to that, however, having them as the default would make porting code from other C-based languages a total nightmare - not to mention it totally shatters the general principle that either C/C++ code is valid D code with the exact same behavior it doesn't compile. That alone makes making them the default untenable. How does making const and/or non-nullable default break this principle? If the code relies on nullable variables, then it won't compile, otherwise it will work exactly the same way as C. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Interfacing to C++
On Friday, October 29, 2010 05:57:15 Trass3r wrote: Over time, more aspects of the C++ ABI may be accessible directly from D Anything in sight? Maybe support for namespaces or some other minor thing? Currently, nothing new there. hmm anything else that makes life with D - C++ easier? I don't think that any work has been done on this. Other things have been higher on the TODO list. - Jonathan M Davis
Re: Streaming library (NG Threading)
On Fri, 29 Oct 2010 16:32:24 +0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 29/10/2010 12:50, Denis Koroskin wrote: On Fri, 29 Oct 2010 15:40:35 +0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 13/10/2010 18:48, Daniel Gibson wrote: Andrei Alexandrescu schrieb: On 10/13/10 11:16 CDT, Denis Koroskin wrote: P.S. For threads this deep it's better fork a new one, especially when changing the subject. I thought I did by changing the title... Andrei At least on my Thunderbird/Icedove 2.0.0.24 it's still in the old Thread. Same here on my Thunderbird 3.0. Is seems TB cares more about the References: field in NNTP message to determine the parent. In fact, with version 3 of TB, it seems that's all it considers... which means that NG messages with the same title as the parent will not be put in the same thread as the parent if they don't have the references field. That sounds like the right approach, however there are some problems in practice because some clients never put the references field (particularly Webnews I think), so all those messages show up in my TB as new threads. :/ Nope, most of the responses through WebNews have correct References in place. All responses that appear as new threads in my TB (ie, threads whose title starts with Re: ) and for which I have looked at the message source, have user agent: User-Agent: Web-News v.1.6.3 (by Terence Yim) and no references field. These messages are common with some posters, like berophile, Sean Kelly, Kagamin,etc.. But some Web-News messages do have a references field though, so it's not all Web-News messages that are missing it. That's strange because here is what I get for a typical WebNews message: Path: digitalmars.com!not-for-mail From: tls d...@notha.ev Newsgroups: digitalmars.D Subject: Re: Lints, Condate and bugs Date: Fri, 29 Oct 2010 15:54:12 +0400 Organization: Digital Mars Lines: 48 Message-ID: iaecl4$9j...@digitalmars.com References: ia6hac$15e...@digitalmars.com op.vlbyabdfo7c...@korden-pc iae6dh$2u1...@digitalmars.com mailman.26.1288350233.21107.digitalmar...@puremagic.com MIME-Version: 1.0 Content-Type: text/plain X-Trace: digitalmars.com 1288353252 9827 65.204.18.192 (29 Oct 2010 11:54:12 GMT) X-Complaints-To: use...@digitalmars.com NNTP-Posting-Date: Fri, 29 Oct 2010 11:54:12 + (UTC) User-Agent: Web-News v.1.6.3 (by Terence Yim) Xref: digitalmars.com digitalmars.D:120649
Re: Ruling out arbitrary cost copy construction?
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s Any tie-breaking arguments, I'm all ears. Andrei Uh...How about that if people want C++, they know where to find it? I think familiarity to C++ programmers is The Wrong Reason (TM) to allow arbitrary cost copy construction. Furthermore, I don't see crufty old C++ programmers as being more important to D than people from other backgrounds. I see D users coming from a variety of backgrounds: 1. Crufty old C/C++ programmers. 2. People who like dynamic languages but need more speed and ability to do low-level work. D is about the most flexible close-to-the-metal/efficient/statically typed language out there. 3. Java/C# programmers who want a language that isn't absurdly verbose. 4. New programmers who don't have much already invested in any other language and want something advanced, modern and w/o tons of legacy cruft. The first **may** want eager copying. The latter three almost certainly won't.
Re: Ruling out arbitrary cost copy construction?
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article To recap: 1. Arbitrary cost copy construction: + Makes value types easy to define: just hook the copying code into this(this) + Is familiar to programmers coming from C++ + If it fails, fails early, not surprisingly during a later operation BTW, I don't see why failing during a variable assignment is any less bad than failing during any other seemingly innocuous operation.
Re: Ruling out arbitrary cost copy construction?
On Friday, October 29, 2010 08:59:51 Andrei Alexandrescu wrote: On 10/29/10 7:55 CDT, Bruno Medeiros wrote: On 06/10/2010 17:57, dsimcha wrote: Vote++. IMHO the problem with arbitrary cost copy construction is that abstractions that are this leaky don't actually make people's lives simpler. Abstractions (like value semantics) are supposed to make the code easier to reason about. When an abstraction forces you to think hard about things as trivial as variable assignments, I think it's better to either scrap the abstraction and require all copying to be explicit, or use a less leaky abstraction like reference counting/COW. I agree with this as well. But I'm still wondering if the original copy construction problem couldn't be solved in some other way. FWIW this matter is still tormenting me. It gridlocks work on ranges, algorithms, and containers. To recap: 1. Arbitrary cost copy construction: + Makes value types easy to define: just hook the copying code into this(this) + Is familiar to programmers coming from C++ + If it fails, fails early, not surprisingly during a later operation - Creates inefficiencies for innocuous-looking code - Contorts code that wants to be efficient - Makes containers, ranges and other abstractions bulkier and more difficult to define, implement, and use - Forces exposure of raw addresses, which hurt abstraction power and safety 2. Constant-cost copy construction (via mandatory refcounting for value types): + Simplifies life virtually everywhere in client code + Makes code easy to reason about (no hidden inefficiencies, failure paths are more visible) + Makes generic code easier to define and more efficient for many types - Makes value types difficult to define: a value type must store all state and do all manipulation indirectly, via a reference-counted pointer; all methods must check the pointer against null; all mutating methods must use a copy-on-write approach - Needs copy-on-write (COW) approaches in defining object types and COW is error-prone because it relies on the programmer remembering to always ensure a unique copy prior to changing the object - Can become a notable difference from C++ (and consequently a contention point for C++ programmers who are considering migrating to D): arbitrary cost of construction hurts C++ in many places, but it has contained the situation with a combination of complexity, discipline, and acceptance of inefficiencies. Any tie-breaking arguments, I'm all ears. Andrei Honestly, what I expect to happen if constant-copy cost is expected is that code won't be written that way and the code that expects a constant-copy cost is going to be slow. Really, I'd say that in the general case, either arbitrary copy construction is going to be expected, and there will be code which assumes constant-copy cost and so is slow, or constant-copy cost construction is going to be expected and any postplits which don't have a constant-copy cost will are going to be inefficient in various places. I really don't think that you have any hope of enforcing either scheme. Programmers just won't think about it in the general case. So, unless the mandatory refcounting for value type (and I have no clue how you'd do that) is actually enforced, you can't enforce either, and you _will_ have inefficiencies. It's just a question of where and what kind. If anything, I'm inclined to say that we assume that the postblit is O(1) and let the programmer worry about any inefficiencies. We can point out that anything worse that O(1) will be a performance problem, but it seems to me that any attempt to either accomodate arbitrary cost postblit constructors or to try and use any kind of scheme which forces programmers to write postblits in a certain way is too complicated and doomed to failure. And even if it works, it will be highly annoying to deal with. - Jonathan M Davis
Re: Ada, SPARK [Was: Re: tolf and detab (language succinctness)]
Bruno Medeiros: I'm not an expert on high-reliability/critical systems, but I had the impression that the majority of it was written in C (even if with restricting code guidelines). Or that at least, much more critical software is written in C than in Ada. Is that not the case? MISRA C is one of the most used high-integrity code guidelines for C: http://en.wikipedia.org/wiki/MISRA_C MISRA C has 127 rules, 93 are required and 34 are advisory. They forbid you lot of things. C language is acceptable for some usages, but it's surely not the best language you may find for high-integrity code, even if your code passes MISRA C tests. I don't know how much Ada is used compared to C in those situations, but I know Ada is used today for those purposes. SPARK is an Ada subset (like MISRA, but smaller) that allows to write stronger code. Even MISRA C guidelines say that: http://www.adahome.com/articles/1998-07/nw_adarecommended.html If D becomes widespread, then someone may write a guidelines (plus testing software to enforce them), like a kind of MISRA D. D is a little safer than C, but I don't know how much fit for those purposes, because sometimes high-integrity code is also embedded. In this regard the good thing of Ada is that it was designed from the start for those purposes, so you start from a better starting point. Numerical computing, high-perfpormance videogames, and medium-integrity code are three of the possible applications I see for the D2 language. The D numerical computing applications will enjoy design ideas from Chapel and X10 languages, while the medium-integrity D applications will enjoy ideas from Ada, SPARK, ATS, MISRA C, etc. Bye, bearophile
Re: Lints, Condate and bugs
On Friday, October 29, 2010 10:04:03 Jérôme M. Berger wrote: Jonathan M Davis wrote: Personally, I think that both would be horrible. Having const is great, and having non-nullable references could be great, but I sure wouldn't want them to be the default. In addition to that, however, having them as the default would make porting code from other C-based languages a total nightmare - not to mention it totally shatters the general principle that either C/C++ code is valid D code with the exact same behavior it doesn't compile. That alone makes making them the default untenable. How does making const and/or non-nullable default break this principle? If the code relies on nullable variables, then it won't compile, otherwise it will work exactly the same way as C. Jerome Hmm. I suppose that in the general case it wouldn't (though the change in syntax for const (what would you do, add mutable or unconst?) would certainly result in a _lot_ of code having to be changed), but once you add in shared libraries having non-nullable be the default could be a problem since the code which deals with the fact that something could be null could be disconnected from the code which actually declares the non-nullable references or pointers such that it compiles just fine, but the code which uses it chokes. But you're right that it's not as bad as I was thinking. Regardless, I don't think that it's a good idea. And this late in the game, even if it were a good idea, I think that we should think long and hard before making that large breaking change. D is supposed to be stabilizing now, not making language changes which break tons of code. - Jonathan M Davis
Re: Ruling out arbitrary cost copy construction?
On 10/29/10 12:18 CDT, dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article To recap: 1. Arbitrary cost copy construction: + Makes value types easy to define: just hook the copying code into this(this) + Is familiar to programmers coming from C++ + If it fails, fails early, not surprisingly during a later operation BTW, I don't see why failing during a variable assignment is any less bad than failing during any other seemingly innocuous operation. One problem is that copying is often implicit and as such more difficult to see with the naked eye. Andrei
Re: Ruling out arbitrary cost copy construction?
On 10/29/10 12:15 CDT, dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s Any tie-breaking arguments, I'm all ears. Andrei Uh...How about that if people want C++, they know where to find it? I think familiarity to C++ programmers is The Wrong Reason (TM) to allow arbitrary cost copy construction. Furthermore, I don't see crufty old C++ programmers as being more important to D than people from other backgrounds. I see D users coming from a variety of backgrounds: 1. Crufty old C/C++ programmers. 2. People who like dynamic languages but need more speed and ability to do low-level work. D is about the most flexible close-to-the-metal/efficient/statically typed language out there. 3. Java/C# programmers who want a language that isn't absurdly verbose. 4. New programmers who don't have much already invested in any other language and want something advanced, modern and w/o tons of legacy cruft. The first **may** want eager copying. The latter three almost certainly won't. Not all C++ programmers are crufty and old :o). Anyhow, there are other advantages to arbitrary cost copy construction, as I specified. For what it's worth, if eliminating it made things overall easier, C++ programmers would have loved it. It's the liabilities I'm worried about. Andrei
Re: Ruling out arbitrary cost copy construction?
On Friday, October 29, 2010 10:15:09 dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s Any tie-breaking arguments, I'm all ears. Andrei Uh...How about that if people want C++, they know where to find it? I think familiarity to C++ programmers is The Wrong Reason (TM) to allow arbitrary cost copy construction. Furthermore, I don't see crufty old C++ programmers as being more important to D than people from other backgrounds. I see D users coming from a variety of backgrounds: 1. Crufty old C/C++ programmers. 2. People who like dynamic languages but need more speed and ability to do low-level work. D is about the most flexible close-to-the-metal/efficient/statically typed language out there. 3. Java/C# programmers who want a language that isn't absurdly verbose. 4. New programmers who don't have much already invested in any other language and want something advanced, modern and w/o tons of legacy cruft. The first **may** want eager copying. The latter three almost certainly won't. Except that how many of those other languages _have_ copy construction? Java doesn't. C#'s classes obviously don't, and IIRC, they're structs don't either (though they may - it's been a while since I used C#). If we're talking about a feature that's pretty much only in C++, then it's a question of whether the C++ programmers are going to be confused and/or surprised and whether someone who has never dealt with such a feature would be confused and/or surprised. Also, for the non-C++ folks who aren't familiar with a feature, they're not going to know about it anyway, so whether you follow C++ or not is irrelevant to them while it is _not_ irrelevant to the C++ programmers. By no means do I think that we should do everything in a particular way just because C++ did it, but particularly when dealing with a feature that is C++- centric, we need to be aware of how what we do will affect C++ programmers. As for eager-coping, it's a _value type_, of _course_ it's going to be copied eagerly. ints, floats, bools, etc. _all_ copy eagerly. How can you expect anything else? It's quite explicit that that's how value types work. So, if you write a struct where copying is expensive, you're asking for trouble and should know it. The only real issue with it that I see is the non-obvious places where copying take place. But if you tried to make it so that structs didn't copy eagerly, then you're making it so that they're not value types anymore which will increas overheard and goes against what structs are meant for. C++ doesn't stop you or help you from being stupid about expensive copy- construction. Why should D? Sure, it sucks when your program is slow, but we have classes which are reference types and don't have this problem. So, if you want a reference type, there it is. I don't see how anyone could expect expensive copying not to result in poor performance for a _value type_. - Jonathan M Davis
Re: Ruling out arbitrary cost copy construction?
On 10/29/10 12:21 CDT, Jonathan M Davis wrote: Honestly, what I expect to happen if constant-copy cost is expected is that code won't be written that way and the code that expects a constant-copy cost is going to be slow. Really, I'd say that in the general case, either arbitrary copy construction is going to be expected, and there will be code which assumes constant-copy cost and so is slow, or constant-copy cost construction is going to be expected and any postplits which don't have a constant-copy cost will are going to be inefficient in various places. I really don't think that you have any hope of enforcing either scheme. That is correct. I don't want to enforce as much as choosing one stance and sticking with it throughout the standard library. The STL is consistently making the following stated assumptions: 1. Functors and iterators are cheap to copy 2. General objects (including containers) are arbitrarily expensive to copy Once STL chose a way, everyone using it could figure out a way to use it gainfully, or to debug performance problems if there were any. Programmers just won't think about it in the general case. So, unless the mandatory refcounting for value type (and I have no clue how you'd do that) is actually enforced, you can't enforce either, and you _will_ have inefficiencies. It's just a question of where and what kind. Walter and I have been seriously discussing introducing @refcounted which would automate part of the process. The problem is you can't automate all or even most of it. Either you must assume client code uses const consistently, or that client code inserts manual calls whenever they plan to change the object. If anything, I'm inclined to say that we assume that the postblit is O(1) and let the programmer worry about any inefficiencies. We can point out that anything worse that O(1) will be a performance problem, but it seems to me that any attempt to either accomodate arbitrary cost postblit constructors or to try and use any kind of scheme which forces programmers to write postblits in a certain way is too complicated and doomed to failure. And even if it works, it will be highly annoying to deal with. It sure is annoying, but it does work. Don, can you estimate how difficult it would be to convert BigInt to a refcounted implementation? Andrei
Re: Ruling out arbitrary cost copy construction?
On 10/29/10 12:53 CDT, Jonathan M Davis wrote: On Friday, October 29, 2010 10:15:09 dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s Any tie-breaking arguments, I'm all ears. Andrei Uh...How about that if people want C++, they know where to find it? I think familiarity to C++ programmers is The Wrong Reason (TM) to allow arbitrary cost copy construction. Furthermore, I don't see crufty old C++ programmers as being more important to D than people from other backgrounds. I see D users coming from a variety of backgrounds: 1. Crufty old C/C++ programmers. 2. People who like dynamic languages but need more speed and ability to do low-level work. D is about the most flexible close-to-the-metal/efficient/statically typed language out there. 3. Java/C# programmers who want a language that isn't absurdly verbose. 4. New programmers who don't have much already invested in any other language and want something advanced, modern and w/o tons of legacy cruft. The first **may** want eager copying. The latter three almost certainly won't. Except that how many of those other languages _have_ copy construction? Java doesn't. C#'s classes obviously don't, and IIRC, they're structs don't either (though they may - it's been a while since I used C#). If we're talking about a feature that's pretty much only in C++, then it's a question of whether the C++ programmers are going to be confused and/or surprised and whether someone who has never dealt with such a feature would be confused and/or surprised. Also, for the non-C++ folks who aren't familiar with a feature, they're not going to know about it anyway, so whether you follow C++ or not is irrelevant to them while it is _not_ irrelevant to the C++ programmers. By no means do I think that we should do everything in a particular way just because C++ did it, but particularly when dealing with a feature that is C++- centric, we need to be aware of how what we do will affect C++ programmers. If the feature had nothing else going for it except being in C++ it would have been eliminated. But value types are a very solid abstraction. We definitely want to support them in D. All - please do not take only one isolated argument from those I listed and focus discussion on it alone. It can only lead to stilted views. As for eager-coping, it's a _value type_, of _course_ it's going to be copied eagerly. ints, floats, bools, etc. _all_ copy eagerly. How can you expect anything else? It's quite explicit that that's how value types work. So, if you write a struct where copying is expensive, you're asking for trouble and should know it. The only real issue with it that I see is the non-obvious places where copying take place. But if you tried to make it so that structs didn't copy eagerly, then you're making it so that they're not value types anymore which will increas overheard and goes against what structs are meant for. In fact reference counting allows you to define value types with cheap copy construction, so the above is incorrect. C++ doesn't stop you or help you from being stupid about expensive copy- construction. Why should D? Sure, it sucks when your program is slow, but we have classes which are reference types and don't have this problem. So, if you want a reference type, there it is. I don't see how anyone could expect expensive copying not to result in poor performance for a _value type_. That means ranges need to define moveFront, moveBack, moveAt, and countless othed contortions in library code and client code alike. I think the view you're conveying is overly simplistic. Andrei
Re: Ruling out arbitrary cost copy construction?
On Friday, October 29, 2010 11:05:02 Andrei Alexandrescu wrote: As for eager-coping, it's a _value type_, of _course_ it's going to be copied eagerly. ints, floats, bools, etc. _all_ copy eagerly. How can you expect anything else? It's quite explicit that that's how value types work. So, if you write a struct where copying is expensive, you're asking for trouble and should know it. The only real issue with it that I see is the non-obvious places where copying take place. But if you tried to make it so that structs didn't copy eagerly, then you're making it so that they're not value types anymore which will increas overheard and goes against what structs are meant for. In fact reference counting allows you to define value types with cheap copy construction, so the above is incorrect. I think I misunderstood what you meant and was thinking reference type rather than ref-counted. C++ doesn't stop you or help you from being stupid about expensive copy- construction. Why should D? Sure, it sucks when your program is slow, but we have classes which are reference types and don't have this problem. So, if you want a reference type, there it is. I don't see how anyone could expect expensive copying not to result in poor performance for a _value type_. That means ranges need to define moveFront, moveBack, moveAt, and countless othed contortions in library code and client code alike. I think the view you're conveying is overly simplistic. I'm arguing that you do _not_ define those and that you let user code fend for itself. If a programmer is foolish enough to write code with overly expensive postblit constructors, then they're just shooting themselves in the foot. - Jonathan M Davis
Re: Ruling out arbitrary cost copy construction?
On 2010-10-29 11:59:51 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: FWIW this matter is still tormenting me. It gridlocks work on ranges, algorithms, and containers. To recap: 1. Arbitrary cost copy construction: + Makes value types easy to define: just hook the copying code into this(this) + Is familiar to programmers coming from C++ + If it fails, fails early, not surprisingly during a later operation - Creates inefficiencies for innocuous-looking code - Contorts code that wants to be efficient - Makes containers, ranges and other abstractions bulkier and more difficult to define, implement, and use - Forces exposure of raw addresses, which hurt abstraction power and safety 2. Constant-cost copy construction (via mandatory refcounting for value types): + Simplifies life virtually everywhere in client code + Makes code easy to reason about (no hidden inefficiencies, failure paths are more visible) + Makes generic code easier to define and more efficient for many types - Makes value types difficult to define: a value type must store all state and do all manipulation indirectly, via a reference-counted pointer; all methods must check the pointer against null; all mutating methods must use a copy-on-write approach - Needs copy-on-write (COW) approaches in defining object types and COW is error-prone because it relies on the programmer remembering to always ensure a unique copy prior to changing the object - Can become a notable difference from C++ (and consequently a contention point for C++ programmers who are considering migrating to D): arbitrary cost of construction hurts C++ in many places, but it has contained the situation with a combination of complexity, discipline, and acceptance of inefficiencies. Most instances of ref-counted structs in Phobos contain race conditions when put on the GC heap. ;-( That's actually a big drawback. Perhaps you should look at what fixing this implies before making this advantage/disadvantage list, as it might get a new negative point (atomic op during copy). http://d.puremagic.com/issues/show_bug.cgi?id=4624 Anyway, my preferred solution to this problem is this third option: 3. Types with arbitrary-cost copying disable this(this) and define explicit dup() function. + Can easily implement either 2 (ref counting) or 1 (arbitrary cost copy constructor) on top of it with a standard template, so you can choose which tradeoff is best for you. + Can live on the stack (ref counting prohibits that). + If it fails, it fails either at compile time when trying to copy implicitly or early at runtime where you call dup explicitly. At this point you can either wrap it in solution 2 (ref counted template) or 1 (arbitrary copy template), or you can change your code to just bypass the problem. - Too much flexibility might be harder to grasp. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Ruling out arbitrary cost copy construction?
On Fri, 29 Oct 2010 20:15:09 +0300, dsimcha dsim...@yahoo.com wrote: 1. Crufty old C/C++ programmers. 2. People who like dynamic languages but need more speed and ability to do low-level work. D is about the most flexible close-to-the-metal/efficient/statically typed language out there. 3. Java/C# programmers who want a language that isn't absurdly verbose. 4. New programmers who don't have much already invested in any other language and want something advanced, modern and w/o tons of legacy cruft. The first **may** want eager copying. The latter three almost certainly won't. If you believe that, you have no valid reason following/using D, with a community like you described you can't get anywhere. Can't speak for other languages or other people but for me if someone is coming from C/C++, not because he sucks but the language is not enough. If you think D is easier by margin, you are delusional. If D being so much easier not the case why do a C user want this nonsense transition? Answer is Quality of life. C/C++ has everything for a crufty old programmer, he doesn't need a transition. Who needs this transition is the ones that pushing the language limits. Some people should really get rid of this C/C++ complex, hate.. I really hate to say this but you got to accept an average C/C++ programmer is much better than best of any higher language programmer. If one argue against this, i got nothing else to say, he needs to wake up and check the games he plays, the OS he uses, anything but simple string processing. Thank you! -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Ruling out arbitrary cost copy construction?
On Friday, October 29, 2010 10:51:17 Andrei Alexandrescu wrote: On 10/29/10 12:21 CDT, Jonathan M Davis wrote: Honestly, what I expect to happen if constant-copy cost is expected is that code won't be written that way and the code that expects a constant-copy cost is going to be slow. Really, I'd say that in the general case, either arbitrary copy construction is going to be expected, and there will be code which assumes constant-copy cost and so is slow, or constant-copy cost construction is going to be expected and any postplits which don't have a constant-copy cost will are going to be inefficient in various places. I really don't think that you have any hope of enforcing either scheme. That is correct. I don't want to enforce as much as choosing one stance and sticking with it throughout the standard library. The STL is consistently making the following stated assumptions: 1. Functors and iterators are cheap to copy 2. General objects (including containers) are arbitrarily expensive to copy Once STL chose a way, everyone using it could figure out a way to use it gainfully, or to debug performance problems if there were any. Programmers just won't think about it in the general case. So, unless the mandatory refcounting for value type (and I have no clue how you'd do that) is actually enforced, you can't enforce either, and you _will_ have inefficiencies. It's just a question of where and what kind. Walter and I have been seriously discussing introducing @refcounted which would automate part of the process. The problem is you can't automate all or even most of it. Either you must assume client code uses const consistently, or that client code inserts manual calls whenever they plan to change the object. If anything, I'm inclined to say that we assume that the postblit is O(1) and let the programmer worry about any inefficiencies. We can point out that anything worse that O(1) will be a performance problem, but it seems to me that any attempt to either accomodate arbitrary cost postblit constructors or to try and use any kind of scheme which forces programmers to write postblits in a certain way is too complicated and doomed to failure. And even if it works, it will be highly annoying to deal with. It sure is annoying, but it does work. Don, can you estimate how difficult it would be to convert BigInt to a refcounted implementation? Okay, then essentially what you're suggesting is that Phobos either 1. Attempts to avoid copying and has constructs such as moveFront() to avoid it. 2. Or makes all of its structs which have arbitrary-cost postblits into reference types which are refcounted and leave user code to fend for itself. If that's the case, then neither really strikes me as much of a departure from C++. In the first case, we are - for better or worse - facilitating code which has expensive postblit constructors. In the second, we're letting them fend for themselves (like C++ does), but are within Phobos using ref-counting for structs with expensive postblits and potentially suggesting that that's what D programmers in general should use when they have structs which are expensive to copy. Unless I'm misunderstanding something here, neither solution is really a departure from C++. It's just that in one case we make what a C++ programmer would likely have done more efficient whereas in the other we're suggesting an idiom which a C++ programmer would likely not have used, but if the C++ programmer programs using an arbitrary-cost postblit like he would have done with an arbitrary-cost copy constructor in C++, the situation is essentially the same as in C++ - except perhaps if it's a expensive to copy a range, which really shouldn't be the case usually. And if both situations aren't all that much of a departure from C++, then it's really a question of which is best for D. The first solution has the advantage that user code doesn't have to care, but it complicates Phobos and the code of anyone looking to write a container type, a range-type, or a range-based algorithm (the worst of those likely being the algorithm since that's the one of the 3 that people are most likely to be doing). So, it hides the issues but imperfectly. In the second solution, anyone writing structs which are expensive to copy needs to care (like they probably should anyway), but Phobos is simplified. In the general case, I'd say that complicating Phobos in favor of simplifying user code would be the correct decision, since it affects the fewest programmers, but ranges are far-reaching enough that it's probably better to go with the second solution (or just outright ignore the issue like I suggested, though if there are any structs in Phobos with arbitrary-cost postblit constructors where this could be an issue, we probably should deal with them - be it by ref- counting or whatever makes the most sense). - Jonathan M
Re: [nomenclature] What is a bug?
On 12/10/2010 14:14, Justin Johansson wrote: Perhaps this topic could be posted as [challenge] Define just exactly what a bug is. I trust this topic will yield some interesting conversation. Cheers Justin Johansson A developer(s) designs a program/system/spec/whatever to exhibit certain behavior. A bug is a behavior exhibited by that creation but which was not intended or expected according to the underlying design. (Design in this context includes the whole source of the program, not just architecture, overall design or something like that.) Unwanted behavior is not a good definition. A behavior can be intended/expected even if is unwanted or undesired. (enhancements, behaviors beyond the control of the program, etc.) -- Bruno Medeiros - Software Engineer
Re: Ruling out arbitrary cost copy construction?
On 10/29/10 13:19 CDT, Jonathan M Davis wrote: I'm arguing that you do _not_ define those and that you let user code fend for itself. If a programmer is foolish enough to write code with overly expensive postblit constructors, then they're just shooting themselves in the foot. I think it would be hasty to classify them as foolish. Expensive copy constructors are meant to protect an abstraction, not some questionable practice. In brief your stance gets back to refcounting: a programmer must choose to use refcounting whenever they have expensive state to manipulate. Andrei
Re: [D typesystem] What is the type of null?
On 13/10/2010 17:27, retard wrote: Tue, 12 Oct 2010 17:41:05 +0200, Simen kjaeraas wrote: Justin Johanssonn...@spam.com wrote: The answer to the OP's question is simple: null's type is not expressible in D. That is a sad observation for a language that purports maturity beyond the epoch of C/C++/Java et. al. I'm curious - why does null need such a specific type? It's much easier to write a specification, a compiler, and an automatic theorem prover for a language with a sane type system. The types and transitions are expressible with simple rules of logic. Now you need ad hoc special cases. Nothing else. It may be true that such would make it easier to write an automatic theorem prover, maybe also a specification, but would it really make it easier to write a compiler for such a language? And more importantly, even if it was easier, would the language actually be a better and more useful language? Better as in a general-purpose programming language. I suspect not, and Justin's implication that D's inability to accurately express the type of null is somehow a severe shortcoming seems to me like wacky formal-methods fanboyism or some other similar crazyness... -- Bruno Medeiros - Software Engineer
Re: [nomenclature] systems language
On 14/10/2010 13:30, Justin Johansson wrote: Touted often around here is the term systems language. May we please discuss a definition to be agreed upon for the usage this term (at least in this community) and also have some agreed upon examples of PLs that might also be members of the set of systems languages. Given a general subjective term like this, one would have to suspect that the D PL is not the only member of this set. Cheers Justin Johansson PS. my apologies for posting a lame joke recently; certainly it was not meant to be disparaging towards the D PL and hopefully it was not taken this way. It's those programming languages whose type systems can be used to move and navigate across water (but can sink if you rock it enough). Compare to other languages whose type systems merely floats on water, but don't move anywhere... (although some guarantee they will never sink no matter how much you rock it!) -- Bruno Medeiros - Software Engineer
Re: What do people here use as an IDE?
On 13/10/2010 03:20, Eric Poggel wrote: On 10/12/2010 10:11 PM, Michael Stover wrote: Descent is a dead project, replaced by DDT which doesn't have a release. Also, I'm running Linux at home and Mac at work, so VisualD won't do for me. Poseidon is also Windows-only. Descent is dead? The change log shows recent activity (http://dsource.org/projects/descent/log/) Descent, the IDE is indeed abandoned, but one of its components, the DMD parser Java port, which resides in the descent.compiler plugin, is still used by DDT. (although in maintenance mode only) Most of that SVN activity is for Mmrnmhrm (now DDT) which was hosted in the same location as Descent up to 09/23/10. The remaining activity is for descent.compiler which is still hosted at the Descent repository. -- Bruno Medeiros - Software Engineer
Re: What do people here use as an IDE?
On 13/10/2010 08:07, Peter Alexander wrote: On 13/10/10 4:15 AM, so wrote: Does Java come with a standard gui library? Yes. Does C come with a standard gui library? No. C didn't need a gui library to be successful, and didn't come with one. On the other hand Java/C# have to have one, packed, and they do come with (at least)one. If your language has a system programming in its feature lists, these kind of libraries have very low priority, let alone specific IDE. C didn't need a GUI library because there was no competition with a GUI library. Like it or not, in this day and age, people expect GUI libraries and IDEs. In fact, most programmers have no idea how to compile code without an IDE. Moreover, most people think that the IDE and the language are the *same thing* (evidenced by the number of people that tag their C++ theory questions as visual studio on stackoverflow.com). I agree that solving the compiler bugs and language issues are top priority, but after that, I'd say IDE and GUI library come next (doesn't have to be a standard GUI library -- just any robust library). I would a say a modern IDE, together with other toolchain programs (debugger, build tools) are much more important than a GUI library. This due to the fact that they would be used by many more developers than those who would want to use a GUI library. -- Bruno Medeiros - Software Engineer
Re: What do people here use as an IDE?
On 13/10/2010 04:15, so wrote: I guess it is wording. Hmm say... Does Java come with a standard gui library? Yes. Does C come with a standard gui library? No. C didn't need a gui library to be successful, and didn't come with one. On the other hand Java/C# have to have one, packed, and they do come with (at least)one. If your language has a system programming in its feature lists, these kind of libraries have very low priority, let alone specific IDE. On Wed, 13 Oct 2010 06:00:16 +0300, Jimmy Cao jcao...@gmail.com wrote: I'm not quite understanding your argument. C and C++ do have *actual* IDE's for them, such as Visual Studio. It's incorrect wording, plain and simple. D != DMD, no one was suggesting DMD should come bundled with an IDE... -- Bruno Medeiros - Software Engineer
Re: Ruling out arbitrary cost copy construction?
Andrei Alexandrescu Wrote: [...] FWIW this matter is still tormenting me. It gridlocks work on ranges, algorithms, and containers. Here's my take: it seems in both cases you're arguing about contorting something in the name of a relatively niche construction. In one case, it's designing libraries around the possibility that you might have an expensive-to-copy value type, and in the other you seem to be seriously contorting the very idea of value type itself. I'm sort of wondering where all these expensive-to-copy value types are going to come from. It's not like writing an expensive-to-copy struct is likely to be something you do by accident, right? I can't think of a case where someone just does it because they know better. A programmer coming from C is likely to naively treat D structs like C structs, and be fine. A programmer coming from Java# or a dynamic scripting language is probably going to be happier sticking to classes and their comforting and familiar reference semantics when they're getting started. That leaves programmers coming from C++, who are likely to know what they're getting themselves into, or more experienced D programmers, who again are likely to know what they're getting themselves into. I think this is a definite worse-is-better situation. Just assume that value types don't have randomly expensive copies in the standard library code, while letting people who want to take the risk of shooting themslves in the foot shoot themselves in the foot by having this(this) open an HTTP collection to Alpha Centauri if that's what they really want. Cheers, Pillsy
Re: What do people here use as an IDE?
On 16/10/2010 10:50, Jérôme M. Berger wrote: Russel Winder wrote: On Wed, 2010-10-13 at 16:24 -0700, Jonathan M Davis wrote: [ . . . ] Proper code completion, correctly jumping to function definitions, and various other features that IDEs generally do well tend to be quite poor in vim. It can do many of them on some level, but for instance, while ctags does give you the ability to jump to function declarations, it does quite poorly in the face of identical variable names across files. There are a number of IDE features that I would love to have and use but vim can't properly pull off. When I have a decent IDE, I'm always torn on whether to use vim or the IDE. vim (well, gvim) generally wins out, but sometimes the extra abilities of the IDE are just too useful. What I'd really like is full-featured IDE with complete and completely remappable vim bindings. Bizarrely the single feature that fails for me in Eclipse, NetBeans and IntelliJ IDEA that I find the single most problematic feature in my programming life -- which means Emacs remains the one true editor -- is formatting comments. I seemingly cannot survive without the ability to reformat the paragraphs of comment blocks to a given width. Emacs handles this trivially in all languages I use for the modes I have. The IDEs seem unable to provide the functionality. Usually they end up reformatting my entire file to some bizarre formatting that is not the one set up for the project. I appreciate that being able to trivially create properly formatted comments is probably uniquely my problem but . . . Same here, no IDE I've seen is able to format code and comments as well as (X)Emacs. Jerome Interesting. For anyone else who shares that opinion, what are the IDE's that you have seen? In particular, does this include JDT? -- Bruno Medeiros - Software Engineer
Re: What do people here use as an IDE?
Bruno Medeiros дµ½: On 13/10/2010 03:20, Eric Poggel wrote: On 10/12/2010 10:11 PM, Michael Stover wrote: Descent is a dead project, replaced by DDT which doesn't have a release. Also, I'm running Linux at home and Mac at work, so VisualD won't do for me. Poseidon is also Windows-only. Descent is dead? The change log shows recent activity (http://dsource.org/projects/descent/log/) Descent, the IDE is indeed abandoned, but one of its components, the DMD parser Java port, which resides in the descent.compiler plugin, is still used by DDT. (although in maintenance mode only) Most of that SVN activity is for Mmrnmhrm (now DDT) which was hosted in the same location as Descent up to 09/23/10. The remaining activity is for descent.compiler which is still hosted at the Descent repository. Bruno Medeiros - Software Engineer Why not continue to maintenance the descent, but to re to develop ddt £¿If you add creative to descent of ddt, will be better, more conservation of resources. thank's dolive
Re: [nomenclature] systems language
Fri, 29 Oct 2010 20:54:03 +0100, Bruno Medeiros wrote: On 14/10/2010 13:30, Justin Johansson wrote: Touted often around here is the term systems language. May we please discuss a definition to be agreed upon for the usage this term (at least in this community) and also have some agreed upon examples of PLs that might also be members of the set of systems languages. Given a general subjective term like this, one would have to suspect that the D PL is not the only member of this set. Cheers Justin Johansson PS. my apologies for posting a lame joke recently; certainly it was not meant to be disparaging towards the D PL and hopefully it was not taken this way. It's those programming languages whose type systems can be used to move and navigate across water (but can sink if you rock it enough). It's probably very hard to find an accurate definition for this kind of term. The same can be said about terms such as 'functional language'. Many 'pragmatic' software engineering terms are based on emotions, broken mental models, inaccurate or purposefully wrong information. In my opinion these are all subtypes of a thing called 'marketing bullshit'. Compare to other languages whose type systems merely floats on water, but don't move anywhere... (although some guarantee they will never sink no matter how much you rock it!) You can easily create a language with guarantees about safety: no segfaults, no index out of bounds errors, no overflows etc. Some of these languages even guarantee termination. However, they're not Turing complete in that case, which reduces their usefulness. Another thing is, these guarantees can be expensive. However, the trend has been towards higher level languages. One reason is Moore's law, you have achieved the same results with a N times slower implementation using the N times faster hardware.
Re: What do people here use as an IDE?
Bruno Medeiros дµ½: On 13/10/2010 03:20, Eric Poggel wrote: On 10/12/2010 10:11 PM, Michael Stover wrote: Descent is a dead project, replaced by DDT which doesn't have a release. Also, I'm running Linux at home and Mac at work, so VisualD won't do for me. Poseidon is also Windows-only. Descent is dead? The change log shows recent activity (http://dsource.org/projects/descent/log/) Descent, the IDE is indeed abandoned, but one of its components, the DMD parser Java port, which resides in the descent.compiler plugin, is still used by DDT. (although in maintenance mode only) Most of that SVN activity is for Mmrnmhrm (now DDT) which was hosted in the same location as Descent up to 09/23/10. The remaining activity is for descent.compiler which is still hosted at the Descent repository. -- Bruno Medeiros - Software Engineer d community too wasteful, too many compilers, too many ide, splitting the standard library thank's dolive
Re: Ruling out arbitrary cost copy construction?
On 10/29/10 15:18 CDT, Pillsy wrote: Andrei Alexandrescu Wrote: [...] FWIW this matter is still tormenting me. It gridlocks work on ranges, algorithms, and containers. Here's my take: it seems in both cases you're arguing about contorting something in the name of a relatively niche construction. In one case, it's designing libraries around the possibility that you might have an expensive-to-copy value type, and in the other you seem to be seriously contorting the very idea of value type itself. Very well put. (Why don't you post more often?) I'm sort of wondering where all these expensive-to-copy value types are going to come from. It's not like writing an expensive-to-copy struct is likely to be something you do by accident, right? I can't think of a case where someone just does it because they know better. The typical case is value types of variable length: strings (the built-in offering notwithstanding), BigInt, BigFloat, STL-style containers, possibly even vectors and matrices (though that's almost always a design mistake). And then of course come types that contain such. So expensive-to-copy is a transitive property that rots everything upwards. In fact let me just add this to the list of pros and cons: 1. Arbitrary cost copy construction: - Propagates through the membership relation, i.e. a struct with at least one costly-to-copy member becomes itself costly-to-copy even though it wasn't planning to or wasn't aware of. 2. Constant-cost copy construction (via mandatory refcounting for value types): + Transparent for the member-of relation, i.e. a constant copy member keeps its containing struct also constant copy. A programmer coming from C is likely to naively treat D structs like C structs, and be fine. Except as noted above. A C programmer might plop a couple of BigInts in a struct and think that they're in good shape. A programmer coming from Java# or a dynamic scripting language is probably going to be happier sticking to classes and their comforting and familiar reference semantics when they're getting started. That leaves programmers coming from C++, who are likely to know what they're getting themselves into, or more experienced D programmers, who again are likely to know what they're getting themselves into. I think this is a definite worse-is-better situation. Just assume that value types don't have randomly expensive copies in the standard library code, while letting people who want to take the risk of shooting themslves in the foot shoot themselves in the foot by having this(this) open an HTTP collection to Alpha Centauri if that's what they really want. Cheers, Pillsy Thanks for the vote. Andrei
Re: What do people here use as an IDE?
Fri, 29 Oct 2010 16:35:38 -0400, dolive wrote: Bruno Medeiros ÐŽµœ: On 13/10/2010 03:20, Eric Poggel wrote: On 10/12/2010 10:11 PM, Michael Stover wrote: Descent is a dead project, replaced by DDT which doesn't have a release. Also, I'm running Linux at home and Mac at work, so VisualD won't do for me. Poseidon is also Windows-only. Descent is dead? The change log shows recent activity (http://dsource.org/projects/descent/log/) Descent, the IDE is indeed abandoned, but one of its components, the DMD parser Java port, which resides in the descent.compiler plugin, is still used by DDT. (although in maintenance mode only) Most of that SVN activity is for Mmrnmhrm (now DDT) which was hosted in the same location as Descent up to 09/23/10. The remaining activity is for descent.compiler which is still hosted at the Descent repository. -- Bruno Medeiros - Software Engineer d community too wasteful, too many compilers, too many ide, splitting the standard library Welcome to the real life. This is open source.
Re: What do people here use as an IDE?
about compiler, for me: - dmd is not full open source - gdc is not a gcc project - ldc is godd compiler but they are some unfixed bug left since a long time ei gtkd build so i choose ldc About ide i use codeblocks and for build my project i use my own makefile system
Re: What do people here use as an IDE?
Bruno Medeiros wrote: On 16/10/2010 10:50, Jérôme M. Berger wrote: Same here, no IDE I've seen is able to format code and comments as well as (X)Emacs. Jerome Interesting. For anyone else who shares that opinion, what are the IDE's that you have seen? In particular, does this include JDT? Well, I don't do any Java development, but it does include CDT... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [D typesystem] What is the type of null?
Bruno Medeiros wrote: On 13/10/2010 17:27, retard wrote: Tue, 12 Oct 2010 17:41:05 +0200, Simen kjaeraas wrote: Justin Johanssonn...@spam.com wrote: The answer to the OP's question is simple: null's type is not expressible in D. That is a sad observation for a language that purports maturity beyond the epoch of C/C++/Java et. al. I'm curious - why does null need such a specific type? It's much easier to write a specification, a compiler, and an automatic theorem prover for a language with a sane type system. The types and transitions are expressible with simple rules of logic. Now you need ad hoc special cases. Nothing else. It may be true that such would make it easier to write an automatic theorem prover, maybe also a specification, but would it really make it easier to write a compiler for such a language? And more importantly, even if it was easier, would the language actually be a better and more useful language? Better as in a general-purpose programming language. I suspect not, and Justin's implication that D's inability to accurately express the type of null is somehow a severe shortcoming seems to me like wacky formal-methods fanboyism or some other similar crazyness... AFAIK, N/A is a fairly legit theorem outcome (laws involving infinity, or integral of sin(x)/x come to mind).
Re: What do people here use as an IDE?
== Quote from bioinfornatics (bioinfornat...@fedoraproject.org)'s article about compiler, for me: - gdc is not a gcc project How is that a valid excuse?
Re: [nomenclature] systems language
div0 wrote: There's nothing special about a systems language; it's just they have explicit facilities that make certain low level functionality easier to implement. You could implement an OS in BASIC using PEEK/POKE if you mad enough. I suppose it's like the difference between porn and art. It's impossible to write a bureaucratic rule to distinguish them, but it's easy to tell the difference just by looking at the two. I know it when I see it!
Re: What do people here use as an IDE?
yes, is not against you work, it is as a packager point of view. while gdc will be not a gcc project, gdc can not be go in fedora. and gdc do not follow gcc stable version because is not a gcc project Same as said et start of this thread is not against your nice job. I know for gdc becomme a gcc project gdc team need give is right. But if you want really support gcc, you will need become a gcc project ... why wait
Re: Lints, Condate and bugs
On 10/27/2010 4:11 PM, KennyTM~ wrote: On Oct 28, 10 03:36, Eric Poggel wrote: Making size_t signed would have consequences that are largely unknown. Why .length cannot return a signed integer (not size_t) by default? What if you're working in 32-bit mode and want to open a 3GB memory-mapped file? Then you will also need an unsignedLength property. I was talking about the .length property of arrays. std.mmfile.MmFile.length() is already returning a 64-bit number (ulong). Making it 63-bit (long) won't cause it fail with a 3GB memory-mapped file. It had been a while since I used them. For some reason I was thinking they were exposed through a standard array, but that doesn't make sense now that I think about it.
Re: How to initialize static array member variable?
Am 01.10.2010, 13:47 Uhr, schrieb Simen kjaeraas simen.kja...@gmail.com: Oh, and also (if you don't mind my nitpicking), have you profiled invSqrt compared to 1/sqrt? Last time I did, I found that invSqrt was about 50% slower than 1/sqrt. Haven't profiled it yet. The one thing I missed when looking at the code was swizzling, so I implemented it. Feel free to include it if you want Thx, I incorporated it :) I also wanted to allow for swizzled setters, but apparently that's currently not possible[1]. [1]: http://d.puremagic.com/issues/show_bug.cgi?id=620 What a pity!
Re: How to initialize static array member variable?
Trass3r u...@known.com wrote:
I also wanted to allow for swizzled setters, but apparently that's
currently not possible[1].
[1]: http://d.puremagic.com/issues/show_bug.cgi?id=620
What a pity!
Actually, after a bit of hacking, I have found a way:
// new helper function
static private bool noCharsRepeated( string s )
{
foreach ( i, e1; s[0..$-1])
foreach ( e2; s[i+1..$] )
if ( e1 == e2 )
return false;
return true;
}
/// swizzling
template opDispatch( string n ) {
@property Vector!(T,n.length) opDispatch( U... )( U args )
if (allCharsValid(n,xyzw[0..dim]) (U.length == 0 || (U.length == 1
is(U[0] == Vector!(T,n.length)) noCharsRepeated(n
{
static if ( U.length == 1 ) {
static if ( n.length = 1 )
cell[n[0]-'x'] = args[0].cell[0];
static if ( n.length = 2 )
cell[n[1]-'x'] = args[0].cell[1];
static if ( n.length = 3 )
cell[n[2]-'x'] = args[0].cell[2];
static if ( n.length = 4 )
cell[n[3]-'x'] = args[0].cell[3];
}
static if (n.length == 2) return
Vector!(T,n.length)(cell[n[0]-'x'], cell[n[1]-'x']);
static if (n.length == 3) return
Vector!(T,n.length)(cell[n[0]-'x'], cell[n[1]-'x'],
cell[n[2]-'x']);
static if (n.length == 4) return
Vector!(T,n.length)(cell[n[0]-'x'], cell[n[1]-'x'], cell[n[2]-'x'],
cell[n[3]-'x']);
}
}
The signature might not exactly be clean, but it works.
--
Simen
pointer syntax
Hello, I have a little issue with pointer syntax: auto toS = (abc) ; // ok auto toS = abc ; // ok auto toI = (1) ; // Error: constant 1 is not an lvalue auto toI = 1 ; // Error: constant 1 is not an lvalue The only solution I found is: auto i = 1 ; auto toI = i ; It seems to be a pure syntactic problem. But why does it work with strings? abc is no more a lvalue, I guess. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: pointer syntax
spir denis.s...@gmail.com wrote: Hello, I have a little issue with pointer syntax: auto toS = (abc) ; // ok auto toS = abc ; // ok auto toI = (1) ; // Error: constant 1 is not an lvalue auto toI = 1 ; // Error: constant 1 is not an lvalue The only solution I found is: auto i = 1 ; auto toI = i ; It seems to be a pure syntactic problem. But why does it work with strings? abc is no more a lvalue, I guess. It appears that array structs are automatically created in the data segment of the executable, and one may thus get a pointer to them. It does make sense to do it this way, but exposing it to let people access it in this way, not so much. I'd say the string example is a bug. -- Simen
Re: pointer syntax
I have added your example here: http://d.puremagic.com/issues/show_bug.cgi?id=4539 Bye, bearophile
Re: byte byte
On 10/29/2010 10:48 AM, Jesse Phillips wrote:
Because C code will not behave differently
I'm not convinced of this. Proposed counterexample:
// test.d
import std.stdio;
void main(){
ushort x = 0x;
writefln(%08x, ~x+1u);
}
// test.c
#include stdio.h
void main(void){
unsigned short x = 0x;
printf(%08x, ~x+1u);
}
Re: pointer syntax
On Fri, 29 Oct 2010 12:57:39 -0400 bearophile bearophileh...@lycos.com wrote: I have added your example here: http://d.puremagic.com/issues/show_bug.cgi?id=4539 Thank you for your answers. (I'm pleased to see I was not totally stupid to find this behaviour somewhat nonsensical ;-) .) Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: byte byte
Ellery Newcomer Wrote:
On 10/29/2010 10:48 AM, Jesse Phillips wrote:
Because C code will not behave differently
I'm not convinced of this. Proposed counterexample:
// test.d
import std.stdio;
void main(){
ushort x = 0x;
writefln(%08x, ~x+1u);
}
http://ideone.com/OsbTE
// test.c
#include stdio.h
void main(void){
unsigned short x = 0x;
printf(%08x, ~x+1u);
}
http://ideone.com/4S4QO
Ok, truly not what I was thinking would happen. I believe D's behavior to be
correct, but as it is the exact same code I think it is worthy of a bug report.
Re: byte byte
It all depends on how important backwards compatibility with C is (I wish it weren't important). From a machine code point of view, D's behavior probably makes more sense, at least with intel. http://d.puremagic.com/issues/show_bug.cgi?id=5132 On 10/29/2010 01:52 PM, Jesse Phillips wrote: Ok, truly not what I was thinking would happen. I believe D's behavior to be correct, but as it is the exact same code I think it is worthy of a bug report.
[Issue 3020] No description is given why function may not be nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=3020
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #5 from Walter Bright bugzi...@digitalmars.com 2010-10-29
03:21:11 PDT ---
Out of memory errors should be allowed inside nothrow.
Also, I suspect it would be good to disallow:
try
{
...
}
catch (Exception e)
{
/* nothing here */
}
where all exceptions are swallowed and ignored. This kind of thing happens in
Java to work around exception specifications, but I don't see a need for it
here. Of course, there would still be ways to swallow ignore (just put in a
call to a do-nothing function), but such shouldn't be easy.
What do you think?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3020] No description is given why function may not be nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=3020
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #5 from Walter Bright bugzi...@digitalmars.com 2010-10-29
03:21:11 PDT ---
Out of memory errors should be allowed inside nothrow.
Also, I suspect it would be good to disallow:
try
{
...
}
catch (Exception e)
{
/* nothing here */
}
where all exceptions are swallowed and ignored. This kind of thing happens in
Java to work around exception specifications, but I don't see a need for it
here. Of course, there would still be ways to swallow ignore (just put in a
call to a do-nothing function), but such shouldn't be easy.
What do you think?
--- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2010-10-29 03:37:35
PDT ---
There are plenty of cases where you know that a function will never throw but
it's not nothrow (perhaps because it can throw in other circumstances), and
you're forced to catch the Exception anyway (probably because you're in a
nothrow function). Personally, I use assert(0) for such cases.
As long as disallowing empty catch blocks is really for _empty_ catch blocks
(or catch blocks with only a comment), I don't mind. But there are definitely
cases where you want to eat an exception or where there should never be one but
you have to have a try-catch anyway.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 620] Can't use property syntax with a template function
http://d.puremagic.com/issues/show_bug.cgi?id=620 Trass3r mrmoc...@gmx.de changed: What|Removed |Added CC||mrmoc...@gmx.de --- Comment #2 from Trass3r mrmoc...@gmx.de 2010-10-29 03:52:29 PDT --- Yeah opDispatch could be used for vector swizzling setters. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2946] Make 'abstract' mandatory if the class is intended to be abstract
http://d.puremagic.com/issues/show_bug.cgi?id=2946 --- Comment #4 from bearophile_h...@eml.cc 2010-10-29 05:01:02 PDT --- (In reply to comment #2) The compiler is behaving correctly, therefore this is an enhancement request. We need a different term to tell apart true enhancement requests (where someone asks for a new feature or new subfeature) from bugs in the specs. This is a case where the specs are suboptimal, so this is not a true enhancement request, it's a way to fix a little mistake in the D specs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5128] New: Forbid abstract attribute for nonabstract methods
http://d.puremagic.com/issues/show_bug.cgi?id=5128
Summary: Forbid abstract attribute for nonabstract methods
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-10-29 05:08:34 PDT ---
DMD 2.050beta compiles and runs this code with no errors, but bar() is not
actually abstract:
abstract class Foo {
abstract void bar() {}
}
void main() {}
What I expect: A compile-time error, something like:
error(2): abstract method 'bar' of class 'Foo' has a body.
See also bug 2946
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5129] New: More strict 'abstract' management
http://d.puremagic.com/issues/show_bug.cgi?id=5129
Summary: More strict 'abstract' management
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-10-29 05:10:03 PDT ---
DMD 2.050beta compiles this, then it fails at linking time:
abstract class A {
public void foo();
}
class B : A {}
void main() {}
What I expect: A compile-time error generated by the compiler, something like:
error(4): class 'B' is not abstract, yet it doesn't implement abstract method
'foo' of class 'A' it inherits from.
See also bug 2946
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3020] No description is given why function may not be nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=3020
--- Comment #7 from Don clugd...@yahoo.com.au 2010-10-29 05:30:34 PDT ---
(In reply to comment #5)
Out of memory errors should be allowed inside nothrow.
Good. I think so too. That will make nothrow much more useful.
In the existing compiler, they are disallowed.
( void foo() nothrow { auto x = new int; } won't compile).
I just added error messages to specify why it was being disallowed.
It sounds as though the check for nothrow violations should be separated from
the code which determines if a statement can throw. That is, for 'new' and for
asm, we assume that it can throw. But, if it's in a nothrow function, we trust
the programmer.
Then, what happens if an out of memory condition happens in a nothrow function?
Is the program simply terminated?
Also, I suspect it would be good to disallow:
try
{
...
}
catch (Exception e)
{
/* nothing here */
}
where all exceptions are swallowed and ignored. This kind of thing happens in
Java to work around exception specifications, but I don't see a need for it
here. Of course, there would still be ways to swallow ignore (just put in a
call to a do-nothing function), but such shouldn't be easy.
What do you think?
Dunno. It's certainly bad style.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5018] segfault / stack overflow when calling overriden Stream.writeBlock
http://d.puremagic.com/issues/show_bug.cgi?id=5018 Adrian Matoga e...@atari8.info changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Adrian Matoga e...@atari8.info 2010-10-29 08:06:48 PDT --- buggy testcase, shame on me. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5130] New: writeln cannot take delegate
http://d.puremagic.com/issues/show_bug.cgi?id=5130
Summary: writeln cannot take delegate
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com
--- Comment #0 from SHOO zan77...@nifty.com 2010-10-29 08:42:46 PDT ---
writeln, format, Tuple(T).toString and so on cannot take delegate(in trunk
r2116).
This code should compile:
import std.stdio;
void main()
{
writeln({});
}
This bug occurred recently.
On dmd 2.042, this bug doesn't occur.
http://ideone.com/iXHoB
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2608] int[] literal too polysemous
http://d.puremagic.com/issues/show_bug.cgi?id=2608 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED CC||bearophile_h...@eml.cc Resolution||FIXED --- Comment #4 from bearophile_h...@eml.cc 2010-10-29 09:47:02 PDT --- That code works with dmd 2.050. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4539] Refuse assignment to string literal
http://d.puremagic.com/issues/show_bug.cgi?id=4539 --- Comment #6 from bearophile_h...@eml.cc 2010-10-29 09:55:19 PDT --- A related bug found by denis spir: auto p = hello; String literals aren't lvalues, so you can't take their address. Just as you can't tale the address of a decimal literal: auto q = (1); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3020] No description is given why function may not be nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=3020
--- Comment #8 from Walter Bright bugzi...@digitalmars.com 2010-10-29
10:29:39 PDT ---
(In reply to comment #7)
In the existing compiler, they are disallowed.
That's a bug.
( void foo() nothrow { auto x = new int; } won't compile).
I just added error messages to specify why it was being disallowed.
It sounds as though the check for nothrow violations should be separated from
the code which determines if a statement can throw. That is, for 'new' and for
asm, we assume that it can throw. But, if it's in a nothrow function, we trust
the programmer.
Then, what happens if an out of memory condition happens in a nothrow
function?
Is the program simply terminated?
Yes.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5129] More strict 'abstract' management
http://d.puremagic.com/issues/show_bug.cgi?id=5129 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #1 from nfx...@gmail.com 2010-10-29 11:05:45 PDT --- Declarations like foo in your example work roughly like they do in C++ (except that it makes less sense in D). Just look at how object.di works: it's full of bodyless non-abstract methods. All dmd can do is to cause a linking error. Even though it's an obscure feature with questionable value. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3020] No description is given why function may not be nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=3020
Andrei Alexandrescu and...@metalanguage.com changed:
What|Removed |Added
CC||and...@metalanguage.com
--- Comment #9 from Andrei Alexandrescu and...@metalanguage.com 2010-10-29
11:11:26 PDT ---
(In reply to comment #5)
Out of memory errors should be allowed inside nothrow.
Also, I suspect it would be good to disallow:
try
{
...
}
catch (Exception e)
{
/* nothing here */
}
where all exceptions are swallowed and ignored. This kind of thing happens in
Java to work around exception specifications, but I don't see a need for it
here. Of course, there would still be ways to swallow ignore (just put in a
call to a do-nothing function), but such shouldn't be easy.
What do you think?
There are plenty of cases when you want to swallow exceptions, and it's highly
unlikely that anyone would write such a pattern by mistake. So let's keep
allowing it. At best, the compiler could protest that e is not being used and
ask for a nameless catch.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5131] New: [ICE] opAssign and associative arrays (AA) are broken for types != this
http://d.puremagic.com/issues/show_bug.cgi?id=5131
Summary: [ICE] opAssign and associative arrays (AA) are broken
for types != this
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: sandf...@jhu.edu
--- Comment #0 from Rob Jacques sandf...@jhu.edu 2010-10-29 11:42:39 PDT ---
Using DMD 2.050, when trying to assign a value to an associative array that is
not the type of the AA results in an ICE.
Here are two test cases:
import std.variant;
void main() {
Variant[string] a;
a[ICE?] = 1;
}
struct ICE {
ICE opAssign(int x) { return this; }
};
void main() {
ICE[string] a;
a[ICE?] = 1;
}
Note that:
void main() {
Variant[string] a;
a[ICE?] = Variant(1);
}
compiles correctly. See http://d.puremagic.com/issues/show_bug.cgi?id=2451
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5132] New: ~ unary operator silently different from C
http://d.puremagic.com/issues/show_bug.cgi?id=5132
Summary: ~ unary operator silently different from C
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu
--- Comment #0 from Ellery Newcomer ellery-newco...@utulsa.edu 2010-10-29
12:16:39 PDT ---
~ type = type for all integer types in D, however
~ type = int for small integer types in C.
This is a source of silently different behavior between D and C at least in
unsigned integer types.
example:
// test.d
import std.stdio;
void main(){
ushort x = 0x;
writefln(%08x, ~x+1u);
}
// test.c
#include stdio.h
void main(void){
unsigned short x = 0x;
printf(%08x, ~x+1u);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4846] A problem with array of std.typecons.Tuple
http://d.puremagic.com/issues/show_bug.cgi?id=4846 bearophile_h...@eml.cc changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from bearophile_h...@eml.cc 2010-10-29 17:08:23 PDT --- Fixed in dmd 2.050 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3813] Bad writeln of arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3813
--- Comment #8 from bearophile_h...@eml.cc 2010-10-29 17:28:53 PDT ---
import std.stdio, std.range;
void main() {
writeln(iota(5));
}
With DMD 2.050 that program prints:
[0, 1, 2, 3, 4]
But that's not an array, it's a lazy sequence, and I'd like to be able to tell
apart an array from a lazy sequence in a printout.
A possible simple way to tell them apart is to print that lazy range like this,
like an array, but with semicolons instead of commas (in some languages this
syntax is used to tell apart linked lists from arrays, but in D lazy ranges are
probably more common than lists):
[0; 1; 2; 3; 4]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3846] Unexpected BufferedFile output
http://d.puremagic.com/issues/show_bug.cgi?id=3846
--- Comment #1 from bearophile_h...@eml.cc 2010-10-29 17:33:10 PDT ---
The second problem is now fixed, this code compiles, see bug 2718 :
import std.stream: BufferedFile, FileMode;
import std.conv: to;
void main() {
auto fout = new BufferedFile(foo.txt, FileMode.Out);
int x = 10;
fout.write(to!string(x) ~ \n);
fout.close();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3848] functions in std.file don't take symbolic links into account
http://d.puremagic.com/issues/show_bug.cgi?id=3848 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Attachment #770 is|0 |1 obsolete|| --- Comment #21 from Jonathan M Davis jmdavisp...@gmx.com 2010-10-29 19:15:08 PDT --- Created an attachment (id=795) Changes based off of dmd 2.050. Here's the file updated for dmd 2.050. I also added a deprecated alias from fullname to name (which I should have done in the beginning). Other than that, it's essentially the same as before except that it's been updated to reflect the changes in file.d in the official release. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
