Re: This just in: authorless TDPL becomes collector's edition
Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Thanks for all the hard work Andrei. -=mike=- Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:hu3hq6$2f0...@digitalmars.com... Due to a pretty odd mistake at the printer, the first 1000 copies of TDPL will not have the name of the author on their cover. (The name still appears on the back cover and the spine.) The history of printing is rife with rare printing mistakes that have become collector's editions. Preorder now to be among the first 1000 readers who get the authorless TDPL edition. Andrei
Re: This just in: authorless TDPL becomes collector's edition
On 21/06/2010 20:23, Mike James wrote: Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Thanks for all the hard work Andrei. -=mike=- Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:hu3hq6$2f0...@digitalmars.com... Due to a pretty odd mistake at the printer, the first 1000 copies of TDPL will not have the name of the author on their cover. (The name still appears on the back cover and the spine.) The history of printing is rife with rare printing mistakes that have become collector's editions. Preorder now to be among the first 1000 readers who get the authorless TDPL edition. Andrei Mine arrived today too, yay, very pleasant reading so far. Bit confused abgout the free online edition though, does it go *poof* after 45 days? A...
Re: This just in: authorless TDPL becomes collector's edition
I wondered that too - looking at the footer thats added to the PDF file it doesn't mention that it timeouts after 45 days. I guess only Andrei can tell us for sure ;-) -=mike=- Alix Pexton alix.dot.pex...@gmail.dot.com wrote in message news:hvoep9$2ld...@digitalmars.com... On 21/06/2010 20:23, Mike James wrote: Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Thanks for all the hard work Andrei. -=mike=- Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:hu3hq6$2f0...@digitalmars.com... Due to a pretty odd mistake at the printer, the first 1000 copies of TDPL will not have the name of the author on their cover. (The name still appears on the back cover and the spine.) The history of printing is rife with rare printing mistakes that have become collector's editions. Preorder now to be among the first 1000 readers who get the authorless TDPL edition. Andrei Mine arrived today too, yay, very pleasant reading so far. Bit confused abgout the free online edition though, does it go *poof* after 45 days? A...
Re: This just in: authorless TDPL becomes collector's edition
Alix Pexton pisze: On 21/06/2010 20:23, Mike James wrote: Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Where to find this PDF version? I can only see the contents, excerpt from first chapter, and the index. And I can't stand waiting for my paper copy in its long way to PL.
Re: Where will D be in 2015 in the programming language ecosphere?
On Sat, 19 Jun 2010 15:04:21 +0200, Justin Johansson n...@spam.com wrote: Me thinks this both a polite question and a question due of realistic answers. How doth thou respond? Not sure, but what I do think is: If D ran on ARM it would be a favorite for mobile devices, often programs are just too slow when done in Java/C# on a phone. People then have to port to C/C++ to get their app running smoothly again. Javascript programmers could very likely pick up D as their compiled language of choice because it allows them to program in a similar way (closures, maps, delegates). PHP programmers could also pick up D, again because it allows them to program in a similar way (mixing functional and OOP, maps, strings, ...). Both javascript and PHP developers are abundant, which is partly why Facebook use PHP so much.
Re: A web server with D
On Sun, 20 Jun 2010 13:54:26 +0200, Mengu menguka...@gmail.com wrote: Hi, I have been interested in and learning D for a while and currently developing a web development IDE with it. I can say that I have a middle level knowledge that I have been trying to increase. Anyway. I want to develop a web server for Python and Ruby web applications some months later from now, after completing the IDE. But until then I want all my research to be completed and I have enough knowledge that I need to develop this web server, in addition to D and within D. So, my two questions are these: 1) What do I need to know in order to develop a web server, generally? 2) What do I need to know within D to make this good enough? Thanks everyone in advance. read the web server related RFCs, not just HTTP (e.g. also MIME). try to keep everthing re-usable, e.g. make a library and a web server. make sure you allow re-writing of urls according to rules (see apache mod rewrite) and: SSL, Virtual hosts (both named and IP based) (ssl doesn't support name based virtual hosts), access control. Logging is also very important.
Re: main.d(61): Error: temp_[i_] isn't mutable
Hi Andrei,
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 06/20/2010 12:56 PM, Ali Çehreli wrote:
Ben Hanson wrote:
== Quote from Justin Spahr-Summers (justin.spahrsumm...@gmail.com)'s
string is actually an alias for immutable(char)[] (and
similarly for
the other string types), so its contents are not modifiable, though
its
length can be adjusted and contents appended. If you need to be
able to
modify the characters, just use char[] instead. You can then use the
.idup property to get a string afterward.
I'm converted temp_ to CharT[] as suggested, but the conversion back
to a string is failing:
_charset = temp_.idup;
main.d(76): Error: cannot implicitly convert expression (_adDupT((
D58TypeInfo_AT4main14__T5regexTAyaZ18basic_string_token5CharT6__initZ),cast
(string)temp_)) of type immutable(CharT)[] to string
Would it work for you if the regex template took the character type
instead of the string type?
The relevant lines:
template regex(CharT)
{
// ...
alias CharT[] StringT;
StringT _charset;
enum size_t MAX_CHARS = CharT.max + 1;
// ...
_charset = squeeze(_charset.idup).dup;
And then, in main:
regex!(char).basic_string_token token_;
Ali
IMHO it's more general if the regexp took the string type as a
parameter. This is because later that is easier generalizable to
accepting a range that's different from an array.
My dream: to have a compile-time-generated regex engine that can operate
on any input stream.
Andrei
I'm currently using strings for the regex strings themselves. In lexertl, I use
templated free functions what work with iterators, which means input can come
from different sources. This sounds like the kind of thing you are talking
about?
Regards,
Ben
Re: Improving std.regex(p)
== Quote from Ellery Newcomer (ellery-newco...@utulsa.edu)'s article On 06/19/2010 03:35 AM, Ben Hanson wrote: I can't prove what the comlexity is for DFA compilation, but instead, I challenge anyone to show slow compilation times with any DFA compatible regex. As I don't have some D code yet, you could try the current lexertl code (just add a single rule). Compile as Release if using Visual C++, as the iterator debugging kills performance in VC++ 8 or above (one problem I guess wouldn't exist with a D codebase). As I say, the only obvious area for me that hammers compilation times is huge repeats. If you repeat an expression 50, times or something, then yes, you will get a huge machine and it will take time to construct! :-) et unicode? There are papers on tackling this with counting repeats, even for DFAs. If this area interests anyone, please let me know. it does Try this link: http://www.arl.wustl.edu/~mbecchi/files/becchi_ancs2009.pdf
Re: Is there ANY chance we can fix the bitwise operator precedence
Andrei: The intent is to only require a control flow transfer if there is at least one statement after the label. The current switch syntax is already very hairy (even lot of people on this newsgroup are ignorant about some parts of it!) and it contains one or more special cases. So I suggest to avoid adding one more special case. Special cases are bad. Bye, bearophile
Re: Is there ANY chance we can fix the bitwise operator precedence
bearophile wrote: Andrei: The intent is to only require a control flow transfer if there is at least one statement after the label. The current switch syntax is already very hairy (even lot of people on this newsgroup are ignorant about some parts of it!) and it contains one or more special cases. So I suggest to avoid adding one more special case. Special cases are bad. You seem to be doing the best you can to torpedo this proposal by adding an extra requirement to it, which is both painful and useless. Please stop now.
Re: Using Classes as the KeyType (from the Docs)
On Sun, 20 Jun 2010 16:50:04 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Notice I've replaced foo with f Foo is the class, but there's no mention of foo. I'm guessing it was a typo, unless I'm missunderstanding something. Yes, it's a typo. You should file a bug. -Steve
How to erase chars from char[]?
I've changed the code to use CharT[] again, which simplified things
substantially. However, I can't find a way to erase characters from a char[].
Can anyone help?
See the current code below.
Thanks,
Ben
module main;
import std.algorithm;
import std.string;
template regex(CharT)
{
struct basic_string_token
{
bool _negated = false;
CharT[] _charset;
enum size_t MAX_CHARS = CharT.max + 1;
enum size_t START_CHAR = cast(CharT) 0x80 0 ? 0x80 : 0;
this(const bool negated_, ref CharT[] charset_)
{
_negated = negated_;
_charset = charset_;
}
void remove_duplicates()
{
_charset.sort;
_charset = squeeze(_charset.idup).dup;
}
void normalise()
{
if (_charset.length == MAX_CHARS)
{
_negated = !_negated;
_charset.clear();
}
else if (_charset.length MAX_CHARS / 2)
{
negate();
}
}
void negate()
{
CharT curr_char_ = START_CHAR;
CharT[] temp_;
CharT *ptr_;
CharT *curr_ = _charset.ptr;
CharT *end_ = curr_ + _charset.length;
size_t i_ = 0;
_negated = !_negated;
temp_.length = MAX_CHARS - _charset.length;
ptr_ = temp_.ptr;
while (curr_ end_)
{
while (*curr_ curr_char_)
{
*ptr_ = curr_char_;
++ptr_;
++curr_char_;
++i_;
}
++curr_char_;
++curr_;
++i_;
}
for (; i_ MAX_CHARS; ++i_)
{
*ptr_ = curr_char_;
++ptr_;
++curr_char_;
}
_charset = temp_;
}
bool empty()
{
return _charset.length == 0 !_negated;
}
bool any()
{
return _charset.length == 0 _negated;
}
void clear()
{
_negated = false;
_charset.length = 0;
}
void intersect(ref basic_string_token rhs_,
ref basic_string_token overlap_)
{
if ((any () rhs_.any ()) || (_negated == rhs_._negated
!any () !rhs_.any ()))
{
intersect_same_types (rhs_, overlap_);
}
else
{
intersect_diff_types (rhs_, overlap_);
}
}
private:
void intersect_same_types (ref basic_string_token rhs_,
ref basic_string_token overlap_)
{
if (any ())
{
clear ();
overlap_._negated = true;
rhs_.clear ();
}
else
{
CharT *iter_ = _charset.ptr;
CharT *end_ = iter_ + _charset.length;
CharT *rhs_iter_ = rhs_._charset.ptr;
CharT *rhs_end_ = rhs_iter_ + rhs_._charset.length;
overlap_._negated = _negated;
while (iter_ != end_ rhs_iter_ != rhs_end_)
{
if (*iter_ *rhs_iter_)
{
++iter_;
}
else if (*iter_ *rhs_iter_)
{
++rhs_iter_;
}
else
{
overlap_._charset ~= *iter_;
_charset.erase(i_);
iter_ = _charset.ptr;
end_ = iter_ + _charset.length;
rhs_._charset.erase(rhs_i_);
rhs_iter_ = rhs_._charset.ptr;
rhs_end_ = rhs_iter_ +
rhs_._charset.length;
}
}
if (_negated)
{
}
else if (!overlap_._charset.length == 0)
{
normalise ();
Re: How to erase chars from char[]?
Ben Hanson:
However, I can't find a way to erase characters from a char[].
Can anyone help?
If you need to delete the last chars you can just decrease the length. If you
need to delete chars in the middle you can copy items with memmove() and then
decrease the length. You can also write a function to do it, this is just a
rough starting point for such function:
import std.range: hasAssignableElements;
import std.c.string: memmove;
/**
this doesn't work with user-defined arrays
it can be made more general, able to work on
Random Access Ranges can can shrink
It can contain a static if that tells apart true D arrays, and uses
memmove() on them, from generic Random Access Ranges, that need a for
loop to copy items.
*/
void remove(T)(ref R[] items, size_t start, size_t stop)
if (hasAssignableElements!R)
in {
assert(stop = start);
assert(items.length = start);
assert(items.length = stop);
} out {
// assert(items.length = old.items.length); // not doable yet
} body {
if (stop == items.length)
items.length = start;
else {
memmove(...);
items.length = ...
}
}
void main() {
char[] s = 012345678.dup;
s.remove(2, 4);
assert(s == ...);
}
Bye,
bearophile
Stack info
Is is possible to add to Phobos standard functions (intrinsics, if necessary) that give some information about the C stack? Things like: - Available space left on the stack (for a thread) - Total size of the stack at program start - The direction of stack growth (see for example http://www.devx.com/tips/Tip/37412 ). - Starting address of the stack Probably on some systems/situations such information is not available, for example the stack can be implemented on a heap, so the function that tells the direction of stack growth can return an enum with three values: UP, DOWN, UNKNOWN. Similar information can be used for low-level programming. I am not expert about this, so maybe this can't be done. For example I've added a small enhancement request for performance that can get better if it knows the available free stack space left (but this is not an usage case, because it's meant to be a feature implemented by the compiler): http://d.puremagic.com/issues/show_bug.cgi?id=4357 Bye, bearophile
Re: enforce()?
On 06/20/2010 11:08 PM, Leandro Lucarella wrote: Walter Bright, el 20 de junio a las 19:32 me escribiste: Leandro Lucarella wrote: Why will you assume I'm so dumb that I won't use your interface correctly? Windows has had major legacy compatibility issues because critical third party applications misused the APIs. People *will* misuse your API, and you will get blamed for it. It's unfair, but that's how it works. Luckily I haven't used Windows for about 10 years now =) It's really a shame that D will take the stupidity route. PS: I don't know how windows work, but if calling the Windows API is like going into kernel mode, and you can mess other processes, it seems reasonable to do check every API call as if it were user input, but if you're confined to your process, is really stupid. Why is it stupid? Andrei
Re: main.d(61): Error: temp_[i_] isn't mutable
On 06/21/2010 03:37 AM, Ben Hanson wrote: I'm currently using strings for the regex strings themselves. In lexertl, I use templated free functions what work with iterators, which means input can come from different sources. This sounds like the kind of thing you are talking about? Regards, Ben Sounds about right! Andrei
Re: How to erase chars from char[]?
On 06/21/2010 06:43 AM, Ben Hanson wrote: I've changed the code to use CharT[] again, which simplified things substantially. However, I can't find a way to erase characters from a char[]. Can anyone help? http://www.digitalmars.com/d/2.0/phobos/std_array.html#replace Andrei
Re: enforce()?
On Mon, 21 Jun 2010 06:08:01 +0200, Leandro Lucarella l...@llucax.com.ar wrote: Walter Bright, el 20 de junio a las 19:32 me escribiste: Leandro Lucarella wrote: Why will you assume I'm so dumb that I won't use your interface correctly? Windows has had major legacy compatibility issues because critical third party applications misused the APIs. People *will* misuse your API, and you will get blamed for it. It's unfair, but that's how it works. Luckily I haven't used Windows for about 10 years now =) It's really a shame that D will take the stupidity route. PS: I don't know how windows work, but if calling the Windows API is like going into kernel mode, and you can mess other processes, it seems reasonable to do check every API call as if it were user input, but if you're confined to your process, is really stupid. I think perhaps you mis-understood, it is mostly not stupidity that causes people to use undocumented features of an API but rather, it is people being overly clever.
Re: enforce()?
Andrei Alexandrescu, el 21 de junio a las 08:02 me escribiste: On 06/20/2010 11:08 PM, Leandro Lucarella wrote: Walter Bright, el 20 de junio a las 19:32 me escribiste: Leandro Lucarella wrote: Why will you assume I'm so dumb that I won't use your interface correctly? Windows has had major legacy compatibility issues because critical third party applications misused the APIs. People *will* misuse your API, and you will get blamed for it. It's unfair, but that's how it works. Luckily I haven't used Windows for about 10 years now =) It's really a shame that D will take the stupidity route. PS: I don't know how windows work, but if calling the Windows API is like going into kernel mode, and you can mess other processes, it seems reasonable to do check every API call as if it were user input, but if you're confined to your process, is really stupid. Why is it stupid? Because you're adding unnecessary extra checks, just based on (Windows?) programmer's stupidity. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- JUGAR COMPULSIVAMENTE ES PERJUDICIAL PARA LA SALUD. -- Casino de Mar del Plata
Re: Improving std.regex(p)
On 06/19/2010 11:27 PM, Ellery Newcomer wrote: On 06/19/2010 10:55 PM, BCS wrote: Hello Nick, BCS n...@anon.com wrote in message news:a6268ff154ca8ccddf1ef51e...@news.digitalmars.com... Hello Ellery, Generally I think D's CT capabilities have a way to go yet before this would be worth tackling. E.g. how do you build a parse tree if pointers and classes aren't allowed in CT code? You use the type system. I can say from experience that (memory issues aside) it works. Trivial example? Building an arbitrary tree: Okay, you use structs without indirection. I guess that works. How much copying does that entail when you e.g. pass your tree in a function call? Nevermind, I see what you're doing now.
Re: Improving std.regex(p)
On 06/21/2010 04:07 AM, Ben Hanson wrote: == Quote from Ellery Newcomer (ellery-newco...@utulsa.edu)'s article On 06/19/2010 03:35 AM, Ben Hanson wrote: I can't prove what the comlexity is for DFA compilation, but instead, I challenge anyone to show slow compilation times with any DFA compatible regex. As I don't have some D code yet, you could try the current lexertl code (just add a single rule). Compile as Release if using Visual C++, as the iterator debugging kills performance in VC++ 8 or above (one problem I guess wouldn't exist with a D codebase). As I say, the only obvious area for me that hammers compilation times is huge repeats. If you repeat an expression 50, times or something, then yes, you will get a huge machine and it will take time to construct! :-) et unicode? There are papers on tackling this with counting repeats, even for DFAs. If this area interests anyone, please let me know. it does Try this link: http://www.arl.wustl.edu/~mbecchi/files/becchi_ancs2009.pdf thanks
Re: Is there ANY chance we can fix the bitwise operator precedence
On Jun 21, 10 17:52, bearophile wrote: Andrei: The intent is to only require a control flow transfer if there is at least one statement after the label. The current switch syntax is already very hairy (even lot of people on this newsgroup are ignorant about some parts of it!) and it contains one or more special cases. So I suggest to avoid adding one more special case. Special cases are bad. Bye, bearophile That is just C#'s switch syntax. And I don't see how the current switch syntax is hairy.
Re: DMD Backend Long-term
dsimcha dsim...@yahoo.com wrote: What is the long-term plan for the current DMD backend? I've noticed the first steps towards 64-bit support were just checked in today (excitement to the extreme). However, the backend is under such a restrictive license (which I understand Walter is not free to change) that it has a bus factor of 1. If Walter were to stop maintaining it, noone else would be able to, if I understand the licensing issues correctly. Is there a chance of these licensing issues being cleared up so that the backend can be released under a more permissive license? If not, while I understand Walter's decision to use a backend he was familiar with in the beginning, it seems like we should abandon such a heavily encumbered backend now that it needs serious work. I think it makes complete sense for the DigitalMars D compiler to use the DigitalMars backend. What we really need is more community work on compilers using other backends (GDC, LLVMDC) as well. The language can only benefit from having more than one compiler available.
Re: Using Classes as the KeyType (from the Docs)
Steven Schveighoffer Wrote: On Sun, 20 Jun 2010 16:50:04 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Notice I've replaced foo with f Foo is the class, but there's no mention of foo. I'm guessing it was a typo, unless I'm missunderstanding something. Yes, it's a typo. You should file a bug. -Steve Will do. But I think I've noticed some more errors in other places, maybe I should try catching as many of them and then do a single report so they all get fixed in a single run.
Re: DMD Backend Long-term
== Quote from dsimcha (dsim...@yahoo.com)'s article What is the long-term plan for the current DMD backend? I've noticed the first steps towards 64-bit support were just checked in today (excitement to the extreme). However, the backend is under such a restrictive license (which I understand Walter is not free to change) that it has a bus factor of 1. If Walter were to stop maintaining it, noone else would be able to, if I understand the licensing issues correctly. Is there a chance of these licensing issues being cleared up so that the backend can be released under a more permissive license? If not, while I understand Walter's decision to use a backend he was familiar with in the beginning, it seems like we should abandon such a heavily encumbered backend now that it needs serious work. Hi I agree with what Sean says. Even more, DMD backend is good for development process, because it is very fast as opposed to more popular ones like llvm or gcc. What really worries me is what is going to happen on Windows. We have the burden which is old file format and optlink. There are still big problems with the linker, it has random problems on big projects, building them with debug info is even more problematic. As far as I understood that linker is being rewritten to C, but the process is very slow. It may take years to complete the port, and then to make it 64bit capable, isn't it? All existing problems would be propagated further. I would suggest(again and again) to add a new Windows backend targeting MinGW or MSVC toolchain. It should not necessarily replace the existing one, but people would at least have freedom and there wouldn't be situation that you are stuck in development when linker fails. Also those toolchain support 64bit, so it is another advantage. For those who still wants digital mars toolchain - there will be an old one. Remembering that it took Walter about 6 weeks to implement MacOS backend, that doesn't seem too bad. In the end, Windows is the most popular OS despite our personal preferences, and it's worth spending some time for it. Cheers
Re: Using Classes as the KeyType (from the Docs)
On Mon, 21 Jun 2010 12:18:47 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Steven Schveighoffer Wrote: On Sun, 20 Jun 2010 16:50:04 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Notice I've replaced foo with f Foo is the class, but there's no mention of foo. I'm guessing it was a typo, unless I'm missunderstanding something. Yes, it's a typo. You should file a bug. -Steve Will do. But I think I've noticed some more errors in other places, maybe I should try catching as many of them and then do a single report so they all get fixed in a single run. That would be great thanks! -Steve
Re: Using Classes as the KeyType (from the Docs)
On 6/21/2010 9:18 AM, Andrej Mitrovic wrote: Steven Schveighoffer Wrote: On Sun, 20 Jun 2010 16:50:04 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Notice I've replaced foo with f Foo is the class, but there's no mention of foo. I'm guessing it was a typo, unless I'm missunderstanding something. Yes, it's a typo. You should file a bug. -Steve Will do. But I think I've noticed some more errors in other places, maybe I should try catching as many of them and then do a single report so they all get fixed in a single run. More small reports would be better than delayed big reports. Just file as you find 'em.
Re: Using Classes as the KeyType (from the Docs)
Brad Roberts Wrote: On 6/21/2010 9:18 AM, Andrej Mitrovic wrote: Steven Schveighoffer Wrote: On Sun, 20 Jun 2010 16:50:04 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Notice I've replaced foo with f Foo is the class, but there's no mention of foo. I'm guessing it was a typo, unless I'm missunderstanding something. Yes, it's a typo. You should file a bug. -Steve Will do. But I think I've noticed some more errors in other places, maybe I should try catching as many of them and then do a single report so they all get fixed in a single run. More small reports would be better than delayed big reports. Just file as you find 'em. It shouldn't take long, maybe a few days or so (and there's probably not *that* many errors, but I have noticed some). Anyways I'll start hunting.
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
KennyTM~ wrote:
On Jun 19, 10 07:17, Jonathan M Davis wrote:
bearophile wrote:
2) switch cases that don't end with goto or break:
void main() {
int x, y;
switch (x) {
case 0: y++;
default: y--;
}
}
I, for one, _want_ case statements to be able to fall through. It would
be horribly painful in many cases if they couldn't. Now, requiring a
separate statement like fallthrough or somesuch instead of break might
not be a bad idea, but requiring that each case end with a break would
seriously restrict the usefulness of switch statements.
- Jonathan M Davis
This fallthrough statement already exists.
switch (x) {
case 0:
do_something();
goto case;
case 1:
do_more_thing();
goto case;
case 2:
done();
break;
default:
error();
break;
}
I forgot about that one. *Sigh* D has so many cool little features that
sometimes it feels like I'm forgetting at least half of them. Oh well. It's
silly to complain that D has too much cool stuff.
In any case, that means that it could be made required to have a control
statement at the end of a case block without having to specify a specific
destination for fallthrough - though I'd prefer continue switch over goto
case since it's more explicit and less error prone (since there's no doubt
that you didn't intend to put a destination for the goto if you use
continue switch instead of a goto case without a destination). But we do
have enough to make a control statement required without adding anything
else to the language.
Thanks for pointing out that little detail of goto.
- Jonathan M Davis
Re: DMD Backend Long-term
Eldar Insafutdinov e.insafutdi...@gmail.com wrote in message news:hvo49k$1uk...@digitalmars.com... In the end, Windows is the most popular OS despite our personal preferences, and it's worth spending some time for it. I wish someone could convince LLVM of that...
Re: Is there ANY chance we can fix the bitwise operator precedence
KennyTM~: That is just C#'s switch syntax. Some of the C# designers are people with a long experience in implementing (Pascal-like) programming languages. Convergent evolution is a way to confirm my idea was good, then :-) And I don't see how the current switch syntax is hairy. Even if you aren't able to see it, it doesn't change the fact that D switch syntax is made by several enhancements (or even fixes, like the one currently discussed, and time ago in bugzilla I have asked for another fix to the switch syntax) over the C switch syntax that is quite unclean and unsafe to start with (see Duff's device for an example of how unclean it is, or the recently introduced static switch of D that patches a common bug source). After about three years of using D I am able to forget that goto case; is a valid syntax. In another answer Jonathan M Davis says something similar: I forgot about that one. *Sigh* D has so many cool little features that sometimes it feels like I'm forgetting at least half of them. Oh well. It's silly to complain that D has too much cool stuff. When normal people forget or ignore parts of a basic language construct it means the language is very complex. The recently introduced ranged case syntax can be handy, but it's not a clean thing. So D switches are quite hairy. Somewhere we'll have to write a short list of the differences between D and C switches. Bye, bearophile
Re: enforce()?
Andrei Alexandrescu Wrote: On 06/20/2010 06:18 PM, Vladimir Panteleev wrote: On Mon, 21 Jun 2010 00:17:28 +0300, Walter Bright newshou...@digitalmars.com wrote: An input to a dll is user input, and should be validated (for the sake of security, and other reasons). Validating it is not debugging. I don't understand why you're saying this. Security checks in DLL functions are pointless, for the reasons I already outlined: [snip] I think the matter is simpler than that. Essentially DbC is modular integrity checking. If Phobos enforce()s parameters in calls, then it considers its own integrity a different matter than the integrity of the application it's used with. If Phobos used contracts to validate parameters, it would directly share responsibility for the integrity of the entire application. That way, users will not be sure whether the failure is a bug in Phobos or one in their own code. If a unrecoverable failure occurs within the process, does it matter where the error originated? I've been thinking about this a bit and am starting to wonder about the benefit of distinguishing API boundary integrity checking vs. internal integrity checking. First, what if a library eats its own dogfood? If my library provides a public method to spawn threads and the library itself uses threads internally then I have two different methods of checking the integrity of my own library, each possibly throwing different exceptions (enforce throws Exception while assert throws AssertError). At the very least, this seems like it could cause maintenance issues because a logic change deep within the library may require additional exception handling to deal with what are intended to be user-facing errors. In a similar vein, if contracts are used within an API but a different mode of checking is used at the API boundary, when contracts are enabled in that API the user is faced with the bizarre issue of receiving AssertErrors from internal API logic errors but only Exceptions from his own logic errors for API boundary calls. When you say that DbC is modular I'd presume that means it's encapsulated within each distinct subsystem, but it seems like this isn't true at all. The alternative is to turn DbC off in the library and either live with undefined behavior or a hard crash if there's a bug in the library, a circumstance which is again forced upon the user. Regarding DbC, I can't say that I've ever worked on a system where lives hung in the balance (an admittedly extreme example of where DbC is useful), but if I were sufficiently concerned about process integrity that I had contracts enabled then I don't think I would trust that a third-party library was bug-free and therefore didn't need its own contract checking in place. Once I've accepted the cost of integrity checking I want it everywhere, not just in my own code. It makes for consistent error checking behavior (I'd assume there is a system in place to trap DbC errors specifically) and provides full-process integrity checking. I think the only boundary that really matters is the process boundary. Any error within a process has the same effect regardless of whether it's in user code or library code--corrupted memory, segfaults, etc--so why make a distinction between code I wrote and code someone else wrote? By the same token, if the user chooses to disable contracts then why force them upon him for some errors but not others? The user is making the explicit choice to run his process through a meat-grinder if something unexpected happens, he's effectively asserting that his code is perfect, so why tell him that no, it's actually not. For me, the more difficult issue is how much integrity checking should be done. For example, I created an AVL tree a while back that verified that the tree was still properly balanced after every API call. This was great from a code verification standpoint, but the check completely violated the complexity guarantees and ultimately checked something that could have been proven to a reasonable degree of confidence through code reviews and unit testing. Should checks like this be enabled automatically when DbC is turned on? Should there be different levels of DbC? In some respects I feel like there's a difference between in/out contracts and invariants, but even that doesn't seem completely right. Thoughts?
Re: enforce()?
Leandro Lucarella pisze: Walter Bright, el 20 de junio a las 19:32 me escribiste: Leandro Lucarella wrote: Why will you assume I'm so dumb that I won't use your interface correctly? Windows has had major legacy compatibility issues because critical third party applications misused the APIs. People *will* misuse your API, and you will get blamed for it. It's unfair, but that's how it works. Luckily I haven't used Windows for about 10 years now =) It's really a shame that D will take the stupidity route. PS: I don't know how windows work, but if calling the Windows API is like going into kernel mode, and you can mess other processes, it seems reasonable to do check every API call as if it were user input, but if you're confined to your process, is really stupid. It was 15 years ago, at the times of 3.x and 95, when Windows behaved like that. The problem applies not only to Windows, but any API you would imagine. A common situation is when you need to do your job quickly using only some part of a library which otherwise you aren't going to study thoroughly, or you want only a proof-of-concept. And if your attempting to use something new to you, you do make mistakes, no matter how you are convinced yo do not. If the API is defined not by documentation (which is often a tissue of lies, and hardly ever it's unambiguous), but by means of input checking, you have benefits in two fields: 1) developers of library had to think what they wanted to do, so library probably works, and it's less probable that its new versions will break the compatiblity, and 2) users of the library will be warned quickly, saving their time. It's not about messing other processes. It's about saving your time, otherwise consumed by effects of common mistakes, misunderstanding the documentation, or working in a hurry. And your time costs much more than the time of bazillion argument checks.
Re: enforce()?
Rory McGuire Wrote: I think perhaps you mis-understood, it is mostly not stupidity that causes people to use undocumented features of an API but rather, it is people being overly clever. Or sometimes simply desperation. There are some classes of apps that require the use of undocumented API calls to operate on Windows--I believe disk defragmenters are one example. Microsoft rightly didn't document these calls because it wasn't prepared to support them long-term, but in doing so they also prevented users from doing necessary work and effectively forced them into using API calls that might change unexpectedly. I think these users accept this problem and do the necessary verification and updating when new OS revisions are released however.
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a control
statement at the end of a case block without having to specify a specific
destination for fallthrough - though I'd prefer continue switch over goto
case since it's more explicit and less error prone (since there's no doubt
that you didn't intend to put a destination for the goto if you use
continue switch instead of a goto case without a destination).
It's a small thing, but I think continue switch could be misleading.
Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation of this
code?
Re: DMD Backend Long-term
On 21/06/10 16:07, dsimcha wrote: What is the long-term plan for the current DMD backend? I've noticed the first steps towards 64-bit support were just checked in today (excitement to the extreme). However, the backend is under such a restrictive license (which I understand Walter is not free to change) that it has a bus factor of 1. If Walter were to stop maintaining it, noone else would be able to, if I understand the licensing issues correctly. Is there a chance of these licensing issues being cleared up so that the backend can be released under a more permissive license? If not, while I understand Walter's decision to use a backend he was familiar with in the beginning, it seems like we should abandon such a heavily encumbered backend now that it needs serious work. Perhaps the 64bit backend could be written in such a way that it doesn't have the licensing issues? I have no idea what the specifics are to say if this is possible, it'd be good to not have the 64 bit backend under the current backend license though.
Re: enforce()?
Sean Kelly:
First, what if a library eats its own dogfood? If my library provides a
public method to spawn threads and the library itself uses threads internally
then I have two different methods of checking the integrity of my own library,
each possibly throwing different exceptions (enforce throws Exception while
assert throws AssertError).
I think that Design by contract, to be useful, needs to be embraced. You need
to trust it and use it everywhere. Now I use DbC quite often in my D code and I
appreciate it. The DbC feature I miss mostly is the old (view of the original
input data).
For example, I created an AVL tree a while back that verified that the tree
was still properly balanced after every API call. This was great from a code
verification standpoint, but the check completely violated the complexity
guarantees and ultimately checked something that could have been proven to a
reasonable degree of confidence through code reviews and unit testing. Should
checks like this be enabled automatically when DbC is turned on? Should there
be different levels of DbC? In some respects I feel like there's a difference
between in/out contracts and invariants, but even that doesn't seem completely
right. Thoughts?
Using Design by Contract is not easy, you need to train yourself to use it
well. A problem is that DbC is uncommon, only Eiffel and few other languages
use it seriously, so lot of D users have to learn DbC on D itself.
I face your problem putting inside the contracts code that doesn't change the
complexity of the code it guards (so for example if the code is O(n^2) I don't
add contracts that perform O(n^3) computations).
Then where it's useful I add stronger tests (that can be slower) inside
debug{}. You can see it here too:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=109395header
Inside the invariant there is O(1) test code, and it also contains inside a
debug{} O(n) test code (that is .
In debug mode I want to test the code very well, while in normal nonrelease
mode I can accept less stringent tests that make the code usable.
Unittests and DbC (and integration tests, functional tests, smoke tests, etc)
are both useful, they do different things :-) For example an unittest can tell
me a function is wrong, but a loop invariant can tell me where the bug is and
when it happens inside the function :-)
Bye,
bearophile
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Sean Kelly: Having never encountered D before, what would be your interpretation of this code? Unfortunately the continue case; syntax looks about equally unintuitive to me :-( Bye, bearophile
finding a circular dependency
I've been trying to get a modified version of std.process to compile (with Lars K's changes) for windows, and phobos finally compiled. So I built a little test program, compiled it, and I get the following error message: object.Exception: circular dependency in module std.stdio. Great. How did that happen? Being that I didn't write std.stdio, only modified it slightly (and certainly didn't change any imports), I haven't the foggiest where this problem is. Given that the runtime can prove there is a circular dependency, and apparently knows the names of the modules, how about showing me the cycle? :P I do not look forward to tracking this one down... -Steve
Errors in TDPL
Okay. I am in no way trying to say anything negative about TDPL. In fact, from what I've read so far, it's absolutely fantastic and quite possibly the most entertaining programming book that I've read in addition to being quite informative about D. However, no one's perfect (Andrei included), and there are bound to be errors in the book which didn't get caught. My thought was that we could point out any errors that we've found so that Andrei can get them fixed in future printings and/or we can find out that they aren't actually errors. The only errors that I've found so far have been omissions in the list of keywords on page 31. I'm listing them according to my understanding of whether they're still keywords, since I think that some have been removed as keywords or at least are no longer supposed to be keywords. Definitely should be there -- immutable lazy pure nothrow shared I _think_ that it's supposed to be there cent ucent I think that they might not supposed to be keywords anymore --- cdouble cfloat creal delete idouble ifloat ireal foreach_reverse Everything under definitely appears to be used in TDPL as keywords but not listed as them. cent and ucent aren't listed, but as far as I know are still keywords (albeit not implemented yet). The ones that are missing which I think have been removed are still listed in the online docs' list of keywards but not in the book. IIRC, the c/i floating points got moved to phobos; according to TDPL, delete was deprecated (though I hadn't picked up on that); and I believe that foreach_reverse has been deprecated in favor of using the combination of foreach and retro. So, TDPL is missing at least some keywords in its list, and the online docs have too many. In any case, I figured that it would be helpful if any errors in TDPL could be pointed out, since it could be helpful to Andrei and could be helpful to those reading it if the error isn't obvious. However, I certainly do _not_ want to in any way indicate displeasure with the book. It's quite good. It's just that it does appear to have some errors in it that snuck through. - Jonathan M Davis
Re: String Literal Docs
On 20/06/2010 22:46, Alix Pexton wrote: On 20/06/2010 21:37, Ellery Newcomer wrote: On 06/20/2010 03:01 PM, Alix Pexton wrote: On 19/06/2010 21:12, Alix Pexton wrote: I've been sketching some grammar diagrams for D2.0, a little like those on JSON.org, and of course I didn't get far before I ran into something odd. I think I will take the plunge and base my diagrams on the source of DMD. After looking at the code in lexer.c, it does not seem as far beyond my rusty old c++ parsing skills as I had expected! Massive credit to Walter for having a codebase that is as mature as DMD without it turning into a labyrinth of preprocessor macros and cryptic comefroms. This will mean however that my little project may take a little longer, sigh... A... Do share. I've always been too lazy to read lexer.c, and from this discussion, it sounds like there are a few spots where my own lexer grammar is incorrect (or at least differs from dmd). of course ^^ A... Well, I think I have got my head around lexer.c now, and its various peculiarities, like 000377. being a valid float (although not according to my shiny new, limited edition copy of tDPL (fig2.2 p35)^^). The weirdness occurs because some of some corner cases are handled not by the neat little state state machine that validates reals, but in the scanner at the point where it recognises a number beginning with a zero. The productions in lex.html represent the range of inputs that are accepted by the state machine without taking into account that the scanner rejects the sequence ._ (which makes sense as that is the identifier _ in the outer scope). Andrei's analysis in tDPL also points out that 0xp0 is a valid hexfloat, but a strict reading of lex.html would not allow it. Overall the diagram for hexfloat is much simpler than the one for decimalfloat, which I think will have to be split into 3 A... PS, octal must die!
Re: This just in: authorless TDPL becomes collector's edition
Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Thanks for all the hard work Andrei. -=mike=- Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:hu3hq6$2f0...@digitalmars.com... Due to a pretty odd mistake at the printer, the first 1000 copies of TDPL will not have the name of the author on their cover. (The name still appears on the back cover and the spine.) The history of printing is rife with rare printing mistakes that have become collector's editions. Preorder now to be among the first 1000 readers who get the authorless TDPL edition. Andrei
Re: This just in: authorless TDPL becomes collector's edition
On 21/06/2010 20:23, Mike James wrote: Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Thanks for all the hard work Andrei. -=mike=- Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:hu3hq6$2f0...@digitalmars.com... Due to a pretty odd mistake at the printer, the first 1000 copies of TDPL will not have the name of the author on their cover. (The name still appears on the back cover and the spine.) The history of printing is rife with rare printing mistakes that have become collector's editions. Preorder now to be among the first 1000 readers who get the authorless TDPL edition. Andrei Mine arrived today too, yay, very pleasant reading so far. Bit confused abgout the free online edition though, does it go *poof* after 45 days? A...
Re: Errors in TDPL
Jonathan M Davis: An online Errata Corrige will be very useful. and I believe that foreach_reverse has been deprecated in favor of using the combination of foreach and retro. How do you write this? foreach_reverse (i; 0 .. 10) Bye, bearophile
Re: This just in: authorless TDPL becomes collector's edition
I wondered that too - looking at the footer thats added to the PDF file it doesn't mention that it timeouts after 45 days. I guess only Andrei can tell us for sure ;-) -=mike=- Alix Pexton alix.dot.pex...@gmail.dot.com wrote in message news:hvoep9$2ld...@digitalmars.com... On 21/06/2010 20:23, Mike James wrote: Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Thanks for all the hard work Andrei. -=mike=- Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:hu3hq6$2f0...@digitalmars.com... Due to a pretty odd mistake at the printer, the first 1000 copies of TDPL will not have the name of the author on their cover. (The name still appears on the back cover and the spine.) The history of printing is rife with rare printing mistakes that have become collector's editions. Preorder now to be among the first 1000 readers who get the authorless TDPL edition. Andrei Mine arrived today too, yay, very pleasant reading so far. Bit confused abgout the free online edition though, does it go *poof* after 45 days? A...
Re: Errors in TDPL
On 21/06/2010 20:09, Jonathan M Davis wrote: Okay. I am in no way trying to say anything negative about TDPL. In fact, from what I've read so far, it's absolutely fantastic and quite possibly the most entertaining programming book that I've read in addition to being quite informative about D. However, no one's perfect (Andrei included), and there are bound to be errors in the book which didn't get caught. My thought was that we could point out any errors that we've found so that Andrei can get them fixed in future printings and/or we can find out that they aren't actually errors. The only errors that I've found so far have been omissions in the list of keywords on page 31. I'm listing them according to my understanding of whether they're still keywords, since I think that some have been removed as keywords or at least are no longer supposed to be keywords. Definitely should be there -- immutable lazy pure nothrow shared I _think_ that it's supposed to be there cent ucent I think that they might not supposed to be keywords anymore --- cdouble cfloat creal delete idouble ifloat ireal foreach_reverse Everything under definitely appears to be used in TDPL as keywords but not listed as them. cent and ucent aren't listed, but as far as I know are still keywords (albeit not implemented yet). The ones that are missing which I think have been removed are still listed in the online docs' list of keywards but not in the book. IIRC, the c/i floating points got moved to phobos; according to TDPL, delete was deprecated (though I hadn't picked up on that); and I believe that foreach_reverse has been deprecated in favor of using the combination of foreach and retro. So, TDPL is missing at least some keywords in its list, and the online docs have too many. In any case, I figured that it would be helpful if any errors in TDPL could be pointed out, since it could be helpful to Andrei and could be helpful to those reading it if the error isn't obvious. However, I certainly do _not_ want to in any way indicate displeasure with the book. It's quite good. It's just that it does appear to have some errors in it that snuck through. - Jonathan M Davis Good Idea! I must admit I skipped over that table, didn't look overly interesting as tables go () but good catch! There is only one mention of lazy evaluation in the index and it doesn't mention the lazy k/w at all. I seem to remember Andrei dislikes it, but also that there is another way to get function params to be evaluated lazily without using it. immutable, nothrow, pure and shared are definitely oversights though. I've not spotted anything D-specific myself yet, I'm not a particularly speedy reader ^^ A...
Re: Errors in TDPL
On 6/21/10, bearophile bearophileh...@lycos.com wrote:
How do you write this?
foreach_reverse (i; 0 .. 10)
foreach(i; retro(iota(0, 10))) { }
?
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Andrei Alexandrescu wrote: On 06/19/2010 06:58 AM, Don wrote: Andrei Alexandrescu wrote: Don wrote: [snip] Or is too late to break backwards compatibility with B ? We can and should do it. It won't impact TDPL adversely. Excellent! I'll make a patch for it when I have time. Walter just gave the green light, so Don - it's up to you. I patched my DMD. Quite successful. It caught 8 bugs in Phobos, in code written by at least 4 different people. I think everyone gets stung by that B.
Re: String Literal Docs
On 06/21/2010 02:21 PM, Alix Pexton wrote: On 20/06/2010 22:46, Alix Pexton wrote: On 20/06/2010 21:37, Ellery Newcomer wrote: On 06/20/2010 03:01 PM, Alix Pexton wrote: On 19/06/2010 21:12, Alix Pexton wrote: I've been sketching some grammar diagrams for D2.0, a little like those on JSON.org, and of course I didn't get far before I ran into something odd. I think I will take the plunge and base my diagrams on the source of DMD. After looking at the code in lexer.c, it does not seem as far beyond my rusty old c++ parsing skills as I had expected! Massive credit to Walter for having a codebase that is as mature as DMD without it turning into a labyrinth of preprocessor macros and cryptic comefroms. This will mean however that my little project may take a little longer, sigh... A... Do share. I've always been too lazy to read lexer.c, and from this discussion, it sounds like there are a few spots where my own lexer grammar is incorrect (or at least differs from dmd). of course ^^ A... Well, I think I have got my head around lexer.c now, and its various peculiarities, like 000377. being a valid float (although not according to my shiny new, limited edition copy of tDPL (fig2.2 p35)^^). Oh wow. That's a sweet little diagram. Those dots are hard to see though. The weirdness occurs because some of some corner cases are handled not by the neat little state state machine that validates reals, but in the scanner at the point where it recognises a number beginning with a zero. The productions in lex.html represent the range of inputs that are accepted by the state machine without taking into account that the scanner rejects the sequence ._ (which makes sense as that is the identifier _ in the outer scope). to hell with lexer.c. I'm not changing anything. Andrei's analysis in tDPL also points out that 0xp0 is a valid hexfloat, but a strict reading of lex.html would not allow it. Overall the diagram for hexfloat is much simpler than the one for decimalfloat, which I think will have to be split into 3 A... PS, octal must die! I'll settle for modified syntax 0c123. But yeah. Are your diagrams solely concerned with the lexer? Because I have a (messy) parser grammar which I'm a bit more confident about if you're interested.
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On 06/21/2010 01:27 PM, Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a control
statement at the end of a case block without having to specify a specific
destination for fallthrough - though I'd prefer continue switch over goto
case since it's more explicit and less error prone (since there's no doubt
that you didn't intend to put a destination for the goto if you use
continue switch instead of a goto case without a destination).
It's a small thing, but I think continue switch could be misleading.
Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation of this
code?
Well looks pretty good to me to be honest.
Andrei
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On 06/21/2010 03:08 PM, Don wrote: Andrei Alexandrescu wrote: On 06/19/2010 06:58 AM, Don wrote: Andrei Alexandrescu wrote: Don wrote: [snip] Or is too late to break backwards compatibility with B ? We can and should do it. It won't impact TDPL adversely. Excellent! I'll make a patch for it when I have time. Walter just gave the green light, so Don - it's up to you. I patched my DMD. Quite successful. It caught 8 bugs in Phobos, in code written by at least 4 different people. I think everyone gets stung by that B. This is pretty amazing. Can't wait to see the checkin! It might be interesting to see how many bugs are caught by restricting the switch statement. Andrei
Re: Errors in TDPL
I was biting my tongue on the subject, but on page 73 the grammar for the do while loop has a semicolon at the end. AAH THERE IS NOOO SEMICOLON AT THE END. Wow. Sorry. This is a pet peeve of mine.
Re: Is there ANY chance we can fix the bitwise operator precedence
Don: I patched my DMD. Quite successful. It caught 8 bugs in Phobos, in code written by at least 4 different people. I think everyone gets stung by that B. Thank you Don. Bye, bearophile
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 06/21/2010 01:27 PM, Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a
control
statement at the end of a case block without having to specify a
specific
destination for fallthrough - though I'd prefer continue switch
over goto
case since it's more explicit and less error prone (since there's
no doubt
that you didn't intend to put a destination for the goto if you use
continue switch instead of a goto case without a destination).
It's a small thing, but I think continue switch could be
misleading. Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation
of this code?
Well looks pretty good to me to be honest.
So would you say done! is printed or not?
Re: Errors in TDPL
Dnia 21-06-2010 o 21:57:49 Alix Pexton alix.dot.pex...@gmail.dot.com napisał(a): There is only one mention of lazy evaluation in the index and it doesn't mention the lazy k/w at all. I seem to remember Andrei dislikes it, but also that there is another way to get function params to be evaluated lazily without using it. Yeah, speaking of which - what happened to that proposal*? *The proposal AFAIR was (correct me if wrong): if a function has a parameterless delegate as a parameter, then on the call site any expression in the delegate slot is implicitly turned into a delegate. I think the delegate ought to be pure to make the magic happen. Yeah, speaking of which - do/will we have pure delegates? Tomek
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On 06/21/2010 03:46 PM, Sean Kelly wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote:
On 06/21/2010 01:27 PM, Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a
control
statement at the end of a case block without having to specify a
specific
destination for fallthrough - though I'd prefer continue switch
over goto
case since it's more explicit and less error prone (since there's
no doubt
that you didn't intend to put a destination for the goto if you use
continue switch instead of a goto case without a destination).
It's a small thing, but I think continue switch could be
misleading. Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation
of this code?
Well looks pretty good to me to be honest.
So would you say done! is printed or not?
I say it isn't because the switch predicate is only evaluated once and
if you change it after evaluation it doesn't matter.
*Placing bet of 5 pixels*
Oh, wait, does 'continue switch' go back up to the top like what
continue does in a loop?
*quietly withdraws bet*
Re: DMD Backend Long-term
Nick Sabalausky, el 21 de junio a las 13:40 me escribiste: Eldar Insafutdinov e.insafutdi...@gmail.com wrote in message news:hvo49k$1uk...@digitalmars.com... In the end, Windows is the most popular OS despite our personal preferences, and it's worth spending some time for it. I wish someone could convince LLVM of that... Maybe it should be the other way around. Someone who cares about Windows should give some love to LLVM =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Es mucho mas probable que el salchichón sea primavera a que la primavera sea salchichón. -- Peperino Pómoro
Re: Errors in TDPL
Adam Ruppe:
foreach(i; retro(iota(0, 10))) { }
Oh, right! Or even just:
foreach (i; retro(iota(10))) {}
But abstraction has a cost, see below. I have written three test programs.
// test1
import std.c.stdio: printf;
void main() {
enum int N = 100_000_000;
int count;
for (int i; i N; i++)
count++;
printf(%d\n, count);
}
Asm of the inner code of the test1, opt version:
5: inc ECX
inc EAX
cmp EAX,05F5E100h
jb L5
// test2
import std.c.stdio: printf;
void main() {
enum int N = 100_000_000;
int count;
foreach_reverse (i; 0 .. N)
count++;
printf(%d\n, count);
}
Asm of the inner code of the test2, opt version:
LF: dec ECX
inc EDX
mov EAX,ECX
inc EAX
jg LF
// test3
import std.c.stdio: printf;
import std.range: iota, retro;
void main() {
enum int N = 100_000_000;
int count;
foreach (i; retro(iota(N)))
count++;
printf(%d\n, count);
}
Asm of the inner code of the test3, opt version:
L6A:inc EBX
lea EAX,010h[ESP]
callnear ptr
_D3std5range145__T4TakeTS3std5range112__T8SequenceVAyaa27_612e6669656c645b305d202b206e202a20612eD0677AACB4B6BC826B92E7DBB9E1E359
cmp dword ptr 020h[ESP],0
jne L6A
_D3std5range145__T4TakeTS3std5range112__T8SequenceVAyaa27_612e6669656c645b305d202b206e202a20612eD0677AACB4B6BC826B92E7DBB9E1E359
comdat
L0: sub ESP,01Ch
mov ECX,offset
FLAT:_D3std5range145__T4TakeTS3std5range112__T8SequenceVAyaa27_612e6669656c645b305d202b206e202a20612e0B5C6D6E0C89B8D48DF56A414048DB6F
pushEBX
pushESI
mov ESI,EAX
mov EDX,010h[ESI]
mov 0Ch[ESP],EAX
neg EDX
sbb EDX,EDX
neg EDX
xor DL,1
mov 010h[ESP],ECX
je L46
mov EDX,ECX
pushdword ptr FLAT:_DATA[064h]
pushdword ptr FLAT:_DATA[060h]
push051Fh
mov EAX,018h[ESP]
mov EBX,018h[ESP]
callEDX
pushEDX
pushEAX
callnear ptr _D3std9contracts7bailOutFAyaixAaZv
L46:dec dword ptr 010h[ESI]
pop ESI
pop EBX
add ESP,01Ch
ret
_D3std9contracts7bailOutFAyaixAaZv is extern.
--
Running time, best of 3, seconds:
test1: 0.31
test1 opt: 0.07
test2: 0.31
test2 opt: 0.12
test3: 6.38
test3 opt: 0.52
not opt version = dmd (no other option)
opt version = dmd -O -release -inline
Compile times opt version, seconds:
test1: 0.05
test2: 0.05
test3: 0.28
So with the current dmd compiler in the inner loop in a performance-critical
routine you can't use foreach(retro(iota(N))).
In future a D compiler can recognize and optimize such usage of foreach(iota())
and foreach(retro(iota())) as ShedSkin does with usage of xrange()/range() in a
loop.
Bye,
bearophile
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a control
statement at the end of a case block without having to specify a specific
destination for fallthrough - though I'd prefer continue switch over
goto case since it's more explicit and less error prone (since there's
no doubt that you didn't intend to put a destination for the goto if you
use continue switch instead of a goto case without a destination).
It's a small thing, but I think continue switch could be misleading.
Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation of
this code?
I hadn't thought of that. That could be a source of confusion. However,
since a switch statement isn't a loop, and it's not a construct in any other
language AFAIK, the person will look it up. Once you've looked it up, I
don't think that it would be particularly hard to remember what it actually
does. It's quite clear what's going once you've become familiar with the
construct and is quite unambiguous in comparison to goto case which could
easily be missing the target case rather than being meant for fallthrough.
So, perhaps it's not immediately intuitive, but many language constructs
are, and I think that it's fairly clear once you've looked it up. Having
something like fallthrough or goto next case would of course be even
clearer, but those would require new keywords. I still think that continue
switch would be clearer than goto case as well as less error prone.
Personally, I think that the fact that it's less error prone alone makes it
a better choice even if it were somewhat less clear.
- Jonathan M Davis
Re: enforce()?
Sean Kelly wrote: Rory McGuire Wrote: I think perhaps you mis-understood, it is mostly not stupidity that causes people to use undocumented features of an API but rather, it is people being overly clever. Or sometimes simply desperation. There are some classes of apps that require the use of undocumented API calls to operate on Windows--I believe disk defragmenters are one example. Microsoft rightly didn't document these calls because it wasn't prepared to support them long-term, but in doing so they also prevented users from doing necessary work and effectively forced them into using API calls that might change unexpectedly. I think these users accept this problem and do the necessary verification and updating when new OS revisions are released however. Remember Windows 3.0? File handling involved undocumented API calls!
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On 06/21/2010 03:46 PM, Sean Kelly wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote:
On 06/21/2010 01:27 PM, Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a
control
statement at the end of a case block without having to specify a
specific
destination for fallthrough - though I'd prefer continue switch
over goto
case since it's more explicit and less error prone (since there's
no doubt
that you didn't intend to put a destination for the goto if you use
continue switch instead of a goto case without a destination).
It's a small thing, but I think continue switch could be
misleading. Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation
of this code?
Well looks pretty good to me to be honest.
So would you say done! is printed or not?
I'd say continue switch does not reevaluate getState() because switch
is not a looping statement. So I'd think it simply continues down, so
writeln is not printed.
But I realize I am biased.
Andrei
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Jonathan M Davis wrote:
Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a control
statement at the end of a case block without having to specify a specific
destination for fallthrough - though I'd prefer continue switch over
goto case since it's more explicit and less error prone (since there's
no doubt that you didn't intend to put a destination for the goto if you
use continue switch instead of a goto case without a destination).
It's a small thing, but I think continue switch could be misleading.
Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation of
this code?
I hadn't thought of that. That could be a source of confusion. However,
since a switch statement isn't a loop, and it's not a construct in any other
language AFAIK, the person will look it up. Once you've looked it up, I
don't think that it would be particularly hard to remember what it actually
does. It's quite clear what's going once you've become familiar with the
construct and is quite unambiguous in comparison to goto case which could
easily be missing the target case rather than being meant for fallthrough.
So, perhaps it's not immediately intuitive, but many language constructs
are, and I think that it's fairly clear once you've looked it up. Having
something like fallthrough or goto next case would of course be even
clearer, but those would require new keywords. I still think that continue
switch would be clearer than goto case as well as less error prone.
Personally, I think that the fact that it's less error prone alone makes it
a better choice even if it were somewhat less clear.
- Jonathan M Davis
But 'goto case XXX' is an extremely rarely encountered construct, that
screams 'Examine this code closely'. So I don't think it needs extra
error checking.
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Don wrote: But 'goto case XXX' is an extremely rarely encountered construct, that screams 'Examine this code closely'. So I don't think it needs extra error checking. Oh, I don't think that it's a big issue. We have goto case XXX and goto case, so we could use them to enforce flow control statements at the end of case blocks without changing anything other than what the compiler complains about. I definitely think that continue switch is less error prone than goto case, and I'd prefer continue switch, but goto case XXX is indeed rare enough that the frequency of screwing up and using goto case instead of goto case XXX would be quite small. So, I definitely find continue switch to be preferable, but it's not a big deal. - Jonathan M Davis
Calling C function with static array includes length and pointer
Hi, I try to pass a static array to a variadic C function. Looks like the array is passed by values as expected, but the length and pointer are prepended, too. Is this intentional or a bug? http://pastebin.com/6ejFF37j
Re: Is there ANY chance we can fix the bitwise operator precedence
Andrei Alexandrescu Wrote:
On 06/21/2010 01:27 PM, Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a control
statement at the end of a case block without having to specify a specific
destination for fallthrough - though I'd prefer continue switch over
goto
case since it's more explicit and less error prone (since there's no doubt
that you didn't intend to put a destination for the goto if you use
continue switch instead of a goto case without a destination).
It's a small thing, but I think continue switch could be misleading.
Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation of
this code?
Well looks pretty good to me to be honest.
So if the initial state is X, is done! printed or not?
Re: Calling C function with static array includes length and pointer
mwarning wrote:
Hi,
I try to pass a static array to a variadic C function.
Looks like the array is passed by values as expected,
but the length and pointer are prepended, too.
Is this intentional or a bug?
http://pastebin.com/6ejFF37j
Fixed sized arrays don't have ptr and length members:
import std.stdio;
void main()
{
int[5] array;
writeln(array.sizeof); // prints 20
writeln(array.ptr, ' ', array); // prints the save value
}
The code you've pasted has this:
extern(C) void* foo(uint x, ...)
{
Stdout(x: )(x).nl;
Stdout(y: )(*(x + 1)).nl; //outputs 64!
return null;
}
The expression *(x + 1) is undefined behavior, because (x + 1) is not
valid, i.e. not specified to be accessible by the language.
Ali
Re: DMD Backend Long-term
In windows if you want use some lib that is not provide dynamic dll support, you need compile it with dmc. In this case your need deal a lot problem with lack of c head file . if there is a vc++ version backend will be big help for a lot of people who is not familiarity with c/c++ . 2010/6/22 Eldar Insafutdinov e.insafutdi...@gmail.com == Quote from dsimcha (dsim...@yahoo.com)'s article What is the long-term plan for the current DMD backend? I've noticed the first steps towards 64-bit support were just checked in today (excitement to the extreme). However, the backend is under such a restrictive license (which I understand Walter is not free to change) that it has a bus factor of 1. If Walter were to stop maintaining it, noone else would be able to, if I understand the licensing issues correctly. Is there a chance of these licensing issues being cleared up so that the backend can be released under a more permissive license? If not, while I understand Walter's decision to use a backend he was familiar with in the beginning, it seems like we should abandon such a heavily encumbered backend now that it needs serious work. Hi I agree with what Sean says. Even more, DMD backend is good for development process, because it is very fast as opposed to more popular ones like llvm or gcc. What really worries me is what is going to happen on Windows. We have the burden which is old file format and optlink. There are still big problems with the linker, it has random problems on big projects, building them with debug info is even more problematic. As far as I understood that linker is being rewritten to C, but the process is very slow. It may take years to complete the port, and then to make it 64bit capable, isn't it? All existing problems would be propagated further. I would suggest(again and again) to add a new Windows backend targeting MinGW or MSVC toolchain. It should not necessarily replace the existing one, but people would at least have freedom and there wouldn't be situation that you are stuck in development when linker fails. Also those toolchain support 64bit, so it is another advantage. For those who still wants digital mars toolchain - there will be an old one. Remembering that it took Walter about 6 weeks to implement MacOS backend, that doesn't seem too bad. In the end, Windows is the most popular OS despite our personal preferences, and it's worth spending some time for it. Cheers
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Jonathan M Davis Wrote:
Sean Kelly wrote:
It's a small thing, but I think continue switch could be misleading.
Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation of
this code?
I hadn't thought of that. That could be a source of confusion. However,
since a switch statement isn't a loop, and it's not a construct in any other
language AFAIK, the person will look it up
...
Personally, I think that the fact that it's less error prone alone makes it
a better choice even if it were somewhat less clear.
I'm inclined to agree. This is just the first thing that popped into my mind
when I saw continue switch and I figured I'd bring it up.
Re: Calling C function with static array includes length and pointer
On Mon, 21 Jun 2010 14:38:50 -0700, Ali Çehreli wrote:
mwarning wrote:
Hi,
I try to pass a static array to a variadic C function. Looks like the
array is passed by values as expected, but the length and pointer are
prepended, too. Is this intentional or a bug?
http://pastebin.com/6ejFF37j
Fixed sized arrays don't have ptr and length members:
import std.stdio;
void main()
{
int[5] array;
writeln(array.sizeof); // prints 20 writeln(array.ptr, '
', array); // prints the save value
}
Hm? You just have proved that they have. :
But those are not members of a struct/pair instance (as for dynamic
arrays). They are compile time values.
Whatever, it's me nitpicking. :)
The code you've pasted has this:
extern(C) void* foo(uint x, ...)
{
Stdout(x: )(x).nl;
Stdout(y: )(*(x + 1)).nl; //outputs 64! return null;
}
The expression *(x + 1) is undefined behavior, because (x + 1) is not
valid, i.e. not specified to be accessible by the language.
Ali
True, the D spec doesn't specify the memory layout.
But the C calling convention does (depending on the platform).
Anyway, the D spec says:
Static arrays are value types, but as in C static arrays are passed to
functions by reference and cannot be returned from functions.
(http://www.digitalmars.com/d/1.0/arrays.html#static-arrays)
It seems that D does a little more then just pass by value. It includes
the pointer and length value as well.
Btw.: smth. told me workaround/solution: wrap the static array in a
struct.
Re: Calling C function with static array includes length and pointer
On 21.06.2010 23:30, mwarning wrote: Hi, I try to pass a static array to a variadic C function. Looks like the array is passed by values as expected, but the length and pointer are prepended, too. Is this intentional or a bug? http://pastebin.com/6ejFF37j I believe this works as intended. And arrays in D 1 are *not* passed by value, ie. the data is not copied. From www.digitalmars.com/d/1.0/arrays.html: a string literal is passed as a (length,pointer) combination to variadic parameters In other words, use stack.ptr if you want just the pointer.
Re: Calling C function with static array includes length and pointer
On Tue, 22 Jun 2010 00:00:27 +0200, torhu wrote: On 21.06.2010 23:30, mwarning wrote: Hi, I try to pass a static array to a variadic C function. Looks like the array is passed by values as expected, but the length and pointer are prepended, too. Is this intentional or a bug? http://pastebin.com/6ejFF37j I believe this works as intended. And arrays in D 1 are *not* passed by value, ie. the data is not copied. From www.digitalmars.com/d/1.0/arrays.html: a string literal is passed as a (length,pointer) combination to variadic parameters Thanks, I missed that section! In other words, use stack.ptr if you want just the pointer. I wrap it into a struct, that will do it.
Re: String Literal Docs
On 21/06/2010 21:20, Ellery Newcomer wrote: Are your diagrams solely concerned with the lexer? Because I have a (messy) parser grammar which I'm a bit more confident about if you're interested. So far I have only covered the lexer, but most of it needs redoing in light of the errors in the DMD docs, but I am hoping to cover the whole spec, eventually... The more I do the quicker I'm able to make them as my workflow evolves, so its hard to say how long it will take... A...
Re: Errors in TDPL
I am only on page ten, I believe I saw a minor typo somewhere in the preface, that's all so far. I look forward to pondering the rest in the coming days. oh yes. Preface D is a language that attempts to consistently do the right thing within the constraints it choose: sys etc missing s, I gues.
Re: Errors in TDPL
On 06/21/2010 02:09 PM, Jonathan M Davis wrote: Okay. I am in no way trying to say anything negative about TDPL. [snip] You are being too kind about this :o). Of course we need an errata list. I was hoping I'd need to set it up later, but hey, that's a sign people actually are reading the book and care about keeping everything in check. I started an errata list in form of a community wiki at http://www.erdani.com/tdpl/errata and primed the errata with your report. Thanks very much! I'll see to it that future printings fix the issues in the errata list. Andrei
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On 06/21/2010 04:15 PM, Don wrote:
Jonathan M Davis wrote:
Sean Kelly wrote:
Jonathan M Davis Wrote:
In any case, that means that it could be made required to have a
control
statement at the end of a case block without having to specify a
specific
destination for fallthrough - though I'd prefer continue switch over
goto case since it's more explicit and less error prone (since
there's
no doubt that you didn't intend to put a destination for the goto if
you
use continue switch instead of a goto case without a destination).
It's a small thing, but I think continue switch could be
misleading. Consider this:
switch (getState()) {
case X:
setState(Z);
continue switch;
case Y:
break;
case Z:
writeln( done! );
}
Having never encountered D before, what would be your interpretation of
this code?
I hadn't thought of that. That could be a source of confusion.
However, since a switch statement isn't a loop, and it's not a
construct in any other language AFAIK, the person will look it up.
Once you've looked it up, I don't think that it would be particularly
hard to remember what it actually does. It's quite clear what's going
once you've become familiar with the construct and is quite
unambiguous in comparison to goto case which could easily be missing
the target case rather than being meant for fallthrough.
So, perhaps it's not immediately intuitive, but many language
constructs are, and I think that it's fairly clear once you've looked
it up. Having something like fallthrough or goto next case would
of course be even clearer, but those would require new keywords. I
still think that continue switch would be clearer than goto case
as well as less error prone. Personally, I think that the fact that
it's less error prone alone makes it a better choice even if it were
somewhat less clear.
- Jonathan M Davis
But 'goto case XXX' is an extremely rarely encountered construct, that
screams 'Examine this code closely'. So I don't think it needs extra
error checking.
After Sean's example, goto case XXX is my fave for fallthrough. I don't
like unlabeled goto case to mean fall through, it's one of those need
to look in the manual features. goto case XXX is generalized fall through.
Andrei
Re: Errors in TDPL
On 06/21/2010 04:06 PM, bearophile wrote:
Adam Ruppe:
foreach(i; retro(iota(0, 10))) { }
Oh, right! Or even just:
foreach (i; retro(iota(10))) {}
But abstraction has a cost, see below. I have written three test programs.
Nice work.
iota() currently uses the formula initial + i * step to compute the ith
element. This is to make sure that iota works properly with floating
point numbers as well as integers.
We should specialize iota for integrals to use increment, which should
count for some efficiency gains (currently the optimizer cannot figure
out the equivalence, so it generates the multiply and add in the loop).
If efficiency is still sub-par, retro could detect that it's working
with iota and generate specialized code. That's not too difficult; for
integers, retro(iota(a, b)) could actually be a rewrite to iota(b - 1,
a, -1). Figuring out all corner cases, steps greater than 1, and what to
do for floating point numbers is doable but not trivial either, and
works against modularity. Anyway, it does look like it's all about an
implementation matter.
Andrei
Re: Errors in TDPL
On 06/21/2010 03:32 PM, Ellery Newcomer wrote: I was biting my tongue on the subject, but on page 73 the grammar for the do while loop has a semicolon at the end. AAH THERE IS NOOO SEMICOLON AT THE END. Wow. Sorry. This is a pet peeve of mine. Can't help that, sorry... Andrei
Re: Calling C function with static array includes length and pointer
mwarning wrote:
Anyway, the D spec says:
Static arrays are value types, but as in C static arrays are passed to
functions by reference and cannot be returned from functions.
(http://www.digitalmars.com/d/1.0/arrays.html#static-arrays)
I've been thinking D2. :) In D2, fixed-sized arrays are value types and
copied to and from functions:
import std.stdio;
int[2] foo(int[2] array)
{
writeln(in foo : , (array[0]));
return array;
}
void main()
{
int[2] array;
writeln(in main 1: , (array[0]));
int[2] result = foo(array);
writeln(in main 2: , (result[0]));
}
All three addresses are separate in D2.
Ali
Re: Errors in TDPL
On 06/21/2010 02:57 PM, Alix Pexton wrote: There is only one mention of lazy evaluation in the index and it doesn't mention the lazy k/w at all. I seem to remember Andrei dislikes it, but also that there is another way to get function params to be evaluated lazily without using it. lazy is quite, no, _very_ ill-defined. Walter and I decided to not mention it in the book and leave room for either a better definition of lazy or a feature that obviates it. Andrei
Re: Errors in TDPL
On 06/21/2010 05:35 PM, Spacen Jasset wrote: I am only on page ten, I believe I saw a minor typo somewhere in the preface, that's all so far. I look forward to pondering the rest in the coming days. oh yes. Preface D is a language that attempts to consistently do the right thing within the constraints it choose: sys etc missing s, I gues. Thanks for your note. The current text uses chose, i.e. the past tense of to choose, so I think it is correct. Andrei
Re: Errors in TDPL
Andrei Alexandrescu wrote: On 06/21/2010 05:35 PM, Spacen Jasset wrote: I am only on page ten, I believe I saw a minor typo somewhere in the preface, that's all so far. I look forward to pondering the rest in the coming days. oh yes. Preface D is a language that attempts to consistently do the right thing within the constraints it choose: sys etc missing s, I gues. Thanks for your note. The current text uses chose, i.e. the past tense of to choose, so I think it is correct. Andrei heh. I can't read. I loose a cookie.
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Andrei Alexandrescu wrote: After Sean's example, goto case XXX is my fave for fallthrough. I don't like unlabeled goto case to mean fall through, it's one of those need to look in the manual features. goto case XXX is generalized fall through. Andrei Well, it definitely works, but then you run into the issue of whether you used the right XXX. That's the kind of place that rearranging code is likely to run into bugs whereas goto case by itself or continue switch would just fall through. It also makes it less obvious when you have errors with goto case XXX being intended to jump somewhere other than the next case. If you're using a statement that is explicitly for falling through, then it's clearly differentiated from a statement where you're jumping to a case other than the next one. I can't say that I'm terribly found of goto case by itself, but at least it would be less likely to cause bugs when rearranging code and more clearly indicates the intention to fall through. It still isn't as good a statement which can only be used for fallthrough (and therefore couldn't be a goto case where you were supposed to put a target but didn't), but I see no advantage in using goto case XXX for fallthrough instead of goto case. goto case does seem a bit silly, but I think that it's clearer and less error prone for anyone who understands goto case. The only issue is the fact that it would be odd for someone who didn't know that you could do that, but there's plenty of that to go around already, and it's not like it would be hard to remember when you see it if you've already looked it up. - Jonathan M Davis
Re: finding a circular dependency
On 06/21/2010 01:51 PM, Steven Schveighoffer wrote: I've been trying to get a modified version of std.process to compile (with Lars K's changes) for windows, and phobos finally compiled. So I built a little test program, compiled it, and I get the following error message: object.Exception: circular dependency in module std.stdio. Great. How did that happen? Being that I didn't write std.stdio, only modified it slightly (and certainly didn't change any imports), I haven't the foggiest where this problem is. Given that the runtime can prove there is a circular dependency, and apparently knows the names of the modules, how about showing me the cycle? :P I do not look forward to tracking this one down... -Steve A long time ago I wrote a utility that finds these cycles. I'll see if I can't kick-start it for D2.
Re: This just in: authorless TDPL becomes collector's edition
Got mine today from Amazon Canada: collector's edition too. I'll start reading it soon! Guillaume Mike James wrote: Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Thanks for all the hard work Andrei. -=mike=- Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:hu3hq6$2f0...@digitalmars.com... Due to a pretty odd mistake at the printer, the first 1000 copies of TDPL will not have the name of the author on their cover. (The name still appears on the back cover and the spine.) The history of printing is rife with rare printing mistakes that have become collector's editions. Preorder now to be among the first 1000 readers who get the authorless TDPL edition. Andrei
Re: This just in: authorless TDPL becomes collector's edition
Alix Pexton pisze: On 21/06/2010 20:23, Mike James wrote: Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Where to find this PDF version? I can only see the contents, excerpt from first chapter, and the index. And I can't stand waiting for my paper copy in its long way to PL.
Re: Errors in TDPL
Andrei Alexandrescu wrote: On 06/21/2010 02:09 PM, Jonathan M Davis wrote: Okay. I am in no way trying to say anything negative about TDPL. [snip] You are being too kind about this :o). Well, I didn't want to post on the main D list and come across as saying that the new book is full of errors and sucks. wIt really is quite an entertaining read (for a programming book anyway) with talk of jumping through rings of syntactic fire, describing casts as well-intended genies, and plenty of other humourous descriptions. And, of course, it's quite instructive along the way. Now if I can only get my co-workers to read it... - Jonathan M Davis
Re: This just in: authorless TDPL becomes collector's edition
I got my collectors edition from Amazon US a few days ago. I browsed it a bit and it looks like an interesting read even for someone who basically knows D already. Which is good, because anyone who knows C or Java basically does already know most of D. I liked that about Stroustrup's book on C++, too, when I read it many moons ago. It had meaty examples that taught me something interesting, even when that wasn't the main language instruction point. For instance, Stroustrup uses a recursive descent parser introduce some mundane aspect of C++ -- statements, I think it was. This book looks like it might have some of that to it. Anyway, thanks for the ack in the preface, Andrei! --bb On Mon, Jun 21, 2010 at 4:05 PM, Guillaume B. guillaume.b.s...@spam.ca wrote: Got mine today from Amazon Canada: collector's edition too. I'll start reading it soon! Guillaume Mike James wrote: Got my collectors item delivered today from Amazon UK. Looks good. I like the bonus of being able to download a PDF version of TDPL. Thanks for all the hard work Andrei. -=mike=- Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:hu3hq6$2f0...@digitalmars.com... Due to a pretty odd mistake at the printer, the first 1000 copies of TDPL will not have the name of the author on their cover. (The name still appears on the back cover and the spine.) The history of printing is rife with rare printing mistakes that have become collector's editions. Preorder now to be among the first 1000 readers who get the authorless TDPL edition. Andrei
Re: Errors in TDPL
On 22.06.2010 00:39, Andrei Alexandrescu wrote: I started an errata list in form of a community wiki at http://www.erdani.com/tdpl/errata For those of us who have still only got the pdf version, is that the same text as the printed one? Should we report errors in the pdf version, or wait until we get the printed edition?
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On 06/21/2010 06:01 PM, Jonathan M Davis wrote: Andrei Alexandrescu wrote: After Sean's example, goto case XXX is my fave for fallthrough. I don't like unlabeled goto case to mean fall through, it's one of those need to look in the manual features. goto case XXX is generalized fall through. Andrei Well, it definitely works, but then you run into the issue of whether you used the right XXX. That's the kind of place that rearranging code is likely to run into bugs whereas goto case by itself or continue switch would just fall through. Here's where statistics come forward: - code that uses fall through: rare - code that uses fall through and needs to be rearranged: rare * rare - code that uses fall through, needs to be rearranged, and the rearranger doesn't even look at the statement IMMEDIATELY PRECEDING the moved case label: rare * rare * rare We're looking at three orders of magnitude here. I think it's reasonable to not dedicate too much language design to this case. It also makes it less obvious when you have errors with goto case XXX being intended to jump somewhere other than the next case. Example that may actually refer to real-world code? Even Duff's device will have a sensible definition, albeit more verbose (which is GOOD): each label action will end with goto case that_label-1. If you're using a statement that is explicitly for falling through, then it's clearly differentiated from a statement where you're jumping to a case other than the next one. I have zero empathy with that distinction. On the contrary, I think code should be written in terms of going from one label handler to another, instead of falling into whatever comes next. I can't say that I'm terribly found of goto case by itself, but at least it would be less likely to cause bugs when rearranging code and more clearly indicates the intention to fall through. Zero.Empathy. It still isn't as good a statement which can only be used for fallthrough (and therefore couldn't be a goto case where you were supposed to put a target but didn't), but I see no advantage in using goto case XXX for fallthrough instead of goto case. I see no disadvantage, and on the contrary, many disadvantages for the cryptic goto case. (What if it means go again to the current case?) The problem is, if Walter sees us bickering too much, he'll use that as pretext to veto out any improvement. goto case does seem a bit silly, but I think that it's clearer No clarity for me. and less error prone for anyone who understands goto case. I don't see that. The only issue is the fact that it would be odd for someone who didn't know that you could do that, but there's plenty of that to go around already, and it's not like it would be hard to remember when you see it if you've already looked it up. Yeah, but it's not like we want to add such cases without necessity. Andrei
Re: Errors in TDPL
On 06/21/2010 06:30 PM, torhu wrote: On 22.06.2010 00:39, Andrei Alexandrescu wrote: I started an errata list in form of a community wiki at http://www.erdani.com/tdpl/errata For those of us who have still only got the pdf version, is that the same text as the printed one? Should we report errors in the pdf version, or wait until we get the printed edition? The PDF on Rough Cuts is identical to the printed book. Please report straight in the errata. Andrei
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On 06/21/2010 05:11 PM, Jonathan M Davis wrote: Having something like fallthrough or goto next case would of course be even clearer, but those would require new keywords. I think fallthrough would be a perfect keyword to add here. C programmers will immediately recognize it. Switch/case are already specialized keywords, and fallthrough can complete the set. It's unlikely to conflict with existing source, and this is one case where having a conspicuously long keyword is a good thing. Finally, goto is ugly and continue is strongly associated with looping.
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Andrei Alexandrescu wrote: [snip] Andrei Well, goto case and goto case XXX both already exist. Both get the job done. So, regardless of which would be better for fallthrough, we can choose to use whichever we want in our code. As it stands, it becomes a matter of preference. I'd love something like continue switch or fallthrough to indicate explicit fallthrough, but it isn't at all necessary, so it's not worth trying to get Walter to add anything like that. At this point, if Walter makes it so that case blocks must end with a flow control statement of some kind, we're free to use either goto case or goto case XXX for fallthrough, so unless goto case is so bad that we should try to get Walter to get rid of it, I don't think that it's really an issue. We can use whichever one we want and not worry about it. The language is complete enough to require case statements to end with a control statement without losing any flexibility, so I think that we can agree to disagree on which statement is better and/or clearer and try and get Walter to add the compiler error for naked fallthrough. - Jonathan M Davis
Re: Is there ANY chance we can fix the bitwise operator precedence
Andrei Alexandrescu: The problem is, if Walter sees us bickering too much, he'll use that as pretext to veto out any improvement. You are wrong, Walter is an adult able to understand discussions, not a capricious dictator :-) Syntax and other things require discussions, sometimes even longish ones. Bye, bearophile
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Did anyone suggest continue case instead of continue switch? That sounds less ambiguous to me. --bb On Mon, Jun 21, 2010 at 4:56 PM, Jonathan M Davis jmdavisp...@gmail.com wrote: Andrei Alexandrescu wrote: [snip] Andrei Well, goto case and goto case XXX both already exist. Both get the job done. So, regardless of which would be better for fallthrough, we can choose to use whichever we want in our code. As it stands, it becomes a matter of preference. I'd love something like continue switch or fallthrough to indicate explicit fallthrough, but it isn't at all necessary, so it's not worth trying to get Walter to add anything like that. At this point, if Walter makes it so that case blocks must end with a flow control statement of some kind, we're free to use either goto case or goto case XXX for fallthrough, so unless goto case is so bad that we should try to get Walter to get rid of it, I don't think that it's really an issue. We can use whichever one we want and not worry about it. The language is complete enough to require case statements to end with a control statement without losing any flexibility, so I think that we can agree to disagree on which statement is better and/or clearer and try and get Walter to add the compiler error for naked fallthrough. - Jonathan M Davis
Re: Is there ANY chance we can fix the bitwise operator precedence
bearophile wrote: Andrei Alexandrescu: The problem is, if Walter sees us bickering too much, he'll use that as pretext to veto out any improvement. You are wrong, Walter is an adult able to understand discussions, not a capricious dictator :-) Syntax and other things require discussions, sometimes even longish ones. Bye, bearophile Yes, he's an adult, but if he's not particularly interested in the change to begin with, and the folks who want the change can't agree on what the change should be, he could easily choose to leave things as they are - especially because things work just fine as they are. We'd like to be able to make a particular error harder to make, but it's not exactly a groundbreaking change. Walter could decide to work on more important things rather than worrying about this one. There's nothing childish about that. - Jonathan M Davis
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On 06/21/2010 06:56 PM, Jonathan M Davis wrote: Andrei Alexandrescu wrote: [snip] Andrei Well, goto case and goto case XXX both already exist. Both get the job done. So, regardless of which would be better for fallthrough, we can choose to use whichever we want in our code. As it stands, it becomes a matter of preference. I'd love something like continue switch or fallthrough to indicate explicit fallthrough, but it isn't at all necessary, so it's not worth trying to get Walter to add anything like that. At this point, if Walter makes it so that case blocks must end with a flow control statement of some kind, we're free to use either goto case or goto case XXX for fallthrough, so unless goto case is so bad that we should try to get Walter to get rid of it, I don't think that it's really an issue. We can use whichever one we want and not worry about it. The language is complete enough to require case statements to end with a control statement without losing any flexibility, so I think that we can agree to disagree on which statement is better and/or clearer and try and get Walter to add the compiler error for naked fallthrough. I think that's fair enough. It's really Walter's decision now, and Don's too (because with Walter busy with the 64-bit implementation, it's likely Don is the one to volunteer to implement the thing). Andrei
Re: Errors in TDPL
Andrei Alexandrescu, el 21 de junio a las 17:43 me escribiste: If efficiency is still sub-par, retro could detect that it's working with iota and generate specialized code. That's not too difficult; for integers, retro(iota(a, b)) could actually be a rewrite to iota(b - 1, a, -1). Figuring out all corner cases, steps greater than 1, and what to do for floating point numbers is doable but not trivial either, and works against modularity. Anyway, it does look like it's all about an implementation matter. I'm scared, I've heard that in C++ so many times... =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- HOMBRE DESNUDO AMENAZA A LOS VECINOS CON UNA KATANA DESDE SU BALCON -- Crónica TV
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
Andrei Alexandrescu, el 21 de junio a las 15:31 me escribiste: On 06/21/2010 03:08 PM, Don wrote: Andrei Alexandrescu wrote: On 06/19/2010 06:58 AM, Don wrote: Andrei Alexandrescu wrote: Don wrote: [snip] Or is too late to break backwards compatibility with B ? We can and should do it. It won't impact TDPL adversely. Excellent! I'll make a patch for it when I have time. Walter just gave the green light, so Don - it's up to you. I patched my DMD. Quite successful. It caught 8 bugs in Phobos, in code written by at least 4 different people. I think everyone gets stung by that B. This is pretty amazing. Can't wait to see the checkin! It might be interesting to see how many bugs are caught by restricting the switch statement. There is already a patch for that: http://d.puremagic.com/issues/show_bug.cgi?id=3536 Maybe is not perfect (it adds a new flavour of case to allow implicit fall-through), but it's something =). And just to experiment with, it should be good enough, since it makes the default case syntax forbids implicit fall-through, so it's not necessary to change any code to try it (if it still applies to trunk, which probably is not the case anymore). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Ya ni el cielo me quiere, ya ni la muerte me visita Ya ni el sol me calienta, ya ni el viento me acaricia
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On Mon, Jun 21, 2010 at 4:24 PM, Leandro Lucarella l...@llucax.com.ar wrote: goto next case; is a little more verbose but very clear to me :) Maybe just next case; is a shorter alternative... That would be great if next were a D keyword. But I don't think you're going to get Walter to add a keyword just for this. --bb
Operator Precedence Table in Online Docs
There is not currently an explicit operator precedence table in the online docs. While C/C++ is close enough that you can generally look at a C/C++ operator precedence table and figure it out if you need to, there are definitely folks who would like a D precedence table to look at (the question has come up on StackOverflow at least once). If nothing else, D does add some operators, and being able to see where they fit in at a quick glance would be useful. Not to mention, ideally, we wouldn't rely on C/C++ documentation to figure out D. In any case, there is a fairly good operator precedence table (well, expression precedence table) in TDPL on pages 61 - 63, and I was thinking that it would be useful if some form of that table ended up in the online documentation at some point. It's something that some folks will definitely be looking for, and while I, personally, wouldn't look at all that often, it is the sort of thing that I'd expect in good online docs for a language. So, anyway, this overly windy post was just to say that we should add an operator precedence table to the online docs. And there's already a good one to work with in TDPL. - Jonathan M Davis
