Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 2012-03-07 21:02, Zach the Mystic wrote: Check it out: https://github.com/zachthemystic/ddmd-clean/ This program is an adaptation of the work done by the ddmd team: http://www.dsource.org/projects/ddmd I described most of it in the README. I hope it runs smoothly for you. I only ran it on MAC OSX, and I don't know much about github or about how to get things running smoothly for others. Don't expect miracles. The parser is NOT up to date, e.g. = with the lastest lambda syntax. I'll gladly put a license on it if the leaders of the community tell me which one to use ( Artistic, libpng, Boost ). Onward and upward to IDE functionality! Zach This looks awesome. -- /Jacob Carlborg
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 2012-03-08 05:54, Jonathan M Davis wrote: On Thursday, March 08, 2012 03:12:48 Zach the Mystic wrote: On Thursday, 8 March 2012 at 01:43:26 UTC, Daniel Murphy wrote: Zach the Mysticreachminusthiszachgm...@dot.com wrote in message news:afqmbmvuvizvgfooe...@forum.dlang.org... I'll gladly put a license on it if the leaders of the community tell me which one to use ( Artistic, libpng, Boost ). Zach It will need to be the same license as the frontend (GPL/Artistic). It should be at the top of each c++ source file. It looks like the license is going to have to be GPL because it says so strictly in dmd's readme.txt. Somehow that license scares me, though. The Free Software Foundation seems like a very Orwellian institution to me. I hope it doesn't scare users away. If you took it from ddmd, then it's definitely going to have to be GPL. Now, there is interest in having a D parser and lexer in Phobos. I don't know if your version will fit the bill (e.g. it must have a range-based API), but we need one at some point. The original idea was to more or less directly port dmd's lexer and parser with some adjustments to the API as necessary (primarily to make it range-based). But no one has had the time to complete such a project yet (I originally volunteered to do it, but I just haven't had the time). When that project was proposed, Walter agreed to let that port be Boost rather than GPL (since he holds the copyright and the port would be going in Phobos, which uses boost). The problem with what you have (even if the API and implementation were perfect) is that it comes from ddmd, which had other contributors working on it. So, you would have to get permission from not only Walter but all of the relevant ddmd contributors. If you were able to _that_, and it could get passed the review process, then what you've done could be put into Phobos. But that requires that you take the time and effort to take care of getting the appropriate permissions, making sure that the API and implementation are acceptable for Phobos, and putting it through the Phobos review process. It would be great if you could do that though. - Jonathan M Davis It would be nice if the frontend written in D (which ever it will be) could be used by DMD. Then there wouldn't be any problems of being out of sync. -- /Jacob Carlborg
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, March 08, 2012 09:11:03 Jacob Carlborg wrote: On 2012-03-08 05:54, Jonathan M Davis wrote: On Thursday, March 08, 2012 03:12:48 Zach the Mystic wrote: On Thursday, 8 March 2012 at 01:43:26 UTC, Daniel Murphy wrote: Zach the Mysticreachminusthiszachgm...@dot.com wrote in message news:afqmbmvuvizvgfooe...@forum.dlang.org... I'll gladly put a license on it if the leaders of the community tell me which one to use ( Artistic, libpng, Boost ). Zach It will need to be the same license as the frontend (GPL/Artistic). It should be at the top of each c++ source file. It looks like the license is going to have to be GPL because it says so strictly in dmd's readme.txt. Somehow that license scares me, though. The Free Software Foundation seems like a very Orwellian institution to me. I hope it doesn't scare users away. If you took it from ddmd, then it's definitely going to have to be GPL. Now, there is interest in having a D parser and lexer in Phobos. I don't know if your version will fit the bill (e.g. it must have a range-based API), but we need one at some point. The original idea was to more or less directly port dmd's lexer and parser with some adjustments to the API as necessary (primarily to make it range-based). But no one has had the time to complete such a project yet (I originally volunteered to do it, but I just haven't had the time). When that project was proposed, Walter agreed to let that port be Boost rather than GPL (since he holds the copyright and the port would be going in Phobos, which uses boost). The problem with what you have (even if the API and implementation were perfect) is that it comes from ddmd, which had other contributors working on it. So, you would have to get permission from not only Walter but all of the relevant ddmd contributors. If you were able to _that_, and it could get passed the review process, then what you've done could be put into Phobos. But that requires that you take the time and effort to take care of getting the appropriate permissions, making sure that the API and implementation are acceptable for Phobos, and putting it through the Phobos review process. It would be great if you could do that though. - Jonathan M Davis It would be nice if the frontend written in D (which ever it will be) could be used by DMD. Then there wouldn't be any problems of being out of sync. Well, having it be easier to keep in sync is one of the reasons that it was originally proposed to simply port the lexer in dmd's frontend to D. But having it _be_ the frontend of dmd would be even better. I don't know how interested Walter is or isn't in that, but having it be a port of the current frontend would likely make convincing him easier than it would be if it were one written from scratch. - Jonathan M davis
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Wednesday, 7 March 2012 at 20:02:57 UTC, Zach the Mystic wrote: https://github.com/zachthemystic/ddmd-clean/ By the way, in compilers, »code generation« is commonly used to refer to the generation of machine code; so using the term to refer to .di file generation/pretty-printing could be misleading for some (it was for me, at least^^). David
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 8 March 2012 22:05, David Nadlinger s...@klickverbot.at wrote: On Wednesday, 7 March 2012 at 20:02:57 UTC, Zach the Mystic wrote: https://github.com/zachthemystic/ddmd-clean/ I would like to see the parser output an AST for use in other situations. It would be nice to have a tool that can analyse the AST and do thing with it (like autocompletion). Clang has done some pretty cool things in this respect, to the point that it can practically do code completion itself. -- James Miller
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, 8 March 2012 at 09:05:05 UTC, David Nadlinger wrote: On Wednesday, 7 March 2012 at 20:02:57 UTC, Zach the Mystic wrote: https://github.com/zachthemystic/ddmd-clean/ By the way, in compilers, »code generation« is commonly used to refer to the generation of machine code; so using the term to refer to .di file generation/pretty-printing could be misleading for some (it was for me, at least^^). David I'm sorry. I see your point. I guess I'll call it pretty-printing, although it also occurred to me to call it disparsing, which then humorously led to the notion dyslexing. Wait, did I spell that right? :-)
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, 8 March 2012 at 04:53:20 UTC, Zach the Mystic wrote: Anyway, the first thing I need is a gui, and a code generator capable of coloring its output appropriately, so I'm working on that, but it's not (even close to) ready for show yet! By Code Generator I actually mean pretty-printer, a distinction I was recently made aware of.
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, 8 March 2012 at 07:49:57 UTC, Jonathan M Davis wrote:
The lexer is going to need to take a range of dchar (which may
or may not be an array),
And while the lexer would need to operate on generic ranges of
dchar, it would probably have to be special-cased for strings
in a number of places
I know what you mean. I actually cut out ddmd's conversion stuff
because I had glanced over phobos I saw plenty of functions
designed for this! I must have intuited what you are saying. dmd
does all conversion to char* prior to sending the buffer to the
lexer. I doubt there's a reason to change this procedure, only to
put that conversion code directly into module dmd.lexer instead.
The parser would then take a range of tokens and then output
the AST in some form or other - it probably couldn't be
range, but I'm not sure.
Dmd's AST is pretty idiosyncratic.
Example: class FuncDeclaration (function declaration ) has a
bunch of named members:
{
Identifier ident; // the function's name
Parameter[] parameters; // its parameters
Statement frequire; // the in{} contract, if present
Statement fbody; // function body
etc.
Each one has its own name. I actually was working on how to turn
it into a more iterable format, since if you want to edit the AST
directly you're going to need to cursor down or up to the element
you want. It's actually doable, but it's not a natural range-ish
format. That's where I'm confused about the licensing issues,
since I'm not sure if the particular object structure which gets
parsed is also going to be in phobos or if it must remain GPL,
which I'm not sure I want to continue using.
So, if you're not familiar with ranges, you probably have a
fair bit of
learning ahead of you, and you're probably going to have to
make a number of
changes to your lexer and parser (though the majority of it
will probably be
able to stay intact). Unfortunately, a proper article and
tutorial on them is
currently lacking in spite of the fact that Phobos uses them
heavily.
Fortunately however, in a book that Ali Çehreli is writing on
D, he has a
chapter on ranges that should help get you started:
http://ddili.org/ders/d.en/ranges.html
But I'd suggest that you play around with ranges a fair bit
(especially with
strings) before trying to change what you have to use them.
std.algorithm in
particular makes heavy use of ranges. And it wouldn't surprise
me at all if
some portions of your lexer and parser really should be using
some of Phobos'
functions but isn't currently, because it's originally a port
from C++. You
should also make sure that you understand the basics of Unicode
fairly well -
especially with how they pertain to char, wchar, and dchar -
since that will
affect your ability to correctly translate code to use ranges
as well as
properly optimize them.
It would probably help if other D developers who are more
familiar with ranges
took a look at what you have and maybe even helped you start
adjusting your
code, but I don't know how many will both have the time and be
interested. If
I have time, I'll probably start poking at it, but I don't know
that I'll have
time any time soon, much as I'd like to.
Regardless, you need to familiarize yourself with ranges if you
want to get
the lexer and parser ready for inclusion in Phobos. And you
really should
familiarize yourself with them anyway, since they're heavily
used in D code in
general. Not being able to use ranges in D would be like not
being able to use
iterators in C++. You can program in it, but you'd be fairly
crippled -
particularly when dealing with the standard library.
- Jonathan M Davis
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
I hit send before I was done writing! On Thursday, 8 March 2012 at 07:49:57 UTC, Jonathan M Davis wrote: Fortunately however, in a book that Ali Çehreli is writing on D, he has a chapter on ranges that should help get you started: http://ddili.org/ders/d.en/ranges.html Thanks. This is a really helpful guide. Okay I'm done!
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 08.03.2012 11:48, Jonathan M Davis wrote: On Thursday, March 08, 2012 08:21:17 Zach the Mystic wrote: On Thursday, 8 March 2012 at 04:56:07 UTC, Jonathan M Davis wrote: If you took it from ddmd, then it's definitely going to have to be GPL. Now, there is interest in having a D parser and lexer in Phobos. I don't know if your version will fit the bill (e.g. it must have a range-based API), but we need one at some point. The original idea was to more or less directly port dmd's lexer and parser with some adjustments to the API as necessary (primarily to make it range-based). But no one has had the time to complete such a project yet (I originally volunteered to do it, but I just haven't had the time). When that project was proposed, Walter agreed to let that port be Boost rather than GPL (since he holds the copyright and the port would be going in Phobos, which uses boost). The problem with what you have (even if the API and implementation were perfect) is that it comes from ddmd, which had other contributors working on it. So, you would have to get permission from not only Walter but all of the relevant ddmd contributors. If you were able to _that_, and it could get passed the review process, then what you've done could be put into Phobos. But that requires that you take the time and effort to take care of getting the appropriate permissions, making sure that the API and implementation are acceptable for Phobos, and putting it through the Phobos review process. It would be great if you could do that though. - Jonathan M Davis This is great news. I was really worried that the license was etched in stone. I'll need help finding out who owns the code, plus legal advice if the process is more than just getting a simple confirmation email from each of the original authors. I have some comments I feel are very interesting regarding the lexer and pointers. There are no pointers in any of the code besides the lexer, so I think that will be very satisfying to you. Now I don't know everything about ranges, but if you simply mean dynamic arrays, then yes, everything except the lexer uses arrays when necessary, although there's simply a lot of code which doesn't need them because most of the objects are really just lists of members, many of which are not arrays. About the lexer, one thing I realized about the Wild-West pointer style as I was porting it is that it must be blazing fast. To my understanding, to call p.popFront() requires two operations, ++p; followed by --p.length; plus possibly array bounds checking, I don't know. ++p is all that the current lexer needs. It used to only check for EOF at each junction, but since I'm parsing little chunks of code instead of whole files now, it checks if ( p= endBuf ) at the beginning of each token scan, which gets pretty close to not going out of bounds, since most tokens aren't very long. That lexer is a tribute to very fast programming of an old school which will go away if it changes. Still, I can sense a tidal wave of RANGES coming, and I fear I'll just have to bid the little thing goodbye! :-( A range is not necessarily a dynamic array, though a dynamic array is a range. The lexer is going to need to take a range of dchar (which may or may not be an array), and it's probably going to need to return a range of tokens. The parser would then take a range of tokens and then output the AST in some form or other - it probably couldn't be range, but I'm not sure. And while the lexer would need to operate on generic ranges of dchar, it would probably have to be special-cased for strings in a number of places in order to make it faster (e.g. checking the first char in a string rather than using front when it's known that the value being checked against is an ASCII character and will therefore fit in a single char - front has to decode the next character, which is less efficient). Simply put, the decisison on decoding should belong to lexer. Thus strings should be wrapped as input range of char, wchar dchar respectively. So, if you're not familiar with ranges, you probably have a fair bit of learning ahead of you, and you're probably going to have to make a number of changes to your lexer and parser (though the majority of it will probably be able to stay intact). Unfortunately, a proper article and tutorial on them is currently lacking in spite of the fact that Phobos uses them heavily. Fortunately however, in a book that Ali Çehreli is writing on D, he has a chapter on ranges that should help get you started: http://ddili.org/ders/d.en/ranges.html But I'd suggest that you play around with ranges a fair bit (especially with strings) before trying to change what you have to use them. std.algorithm in particular makes heavy use of ranges. And it wouldn't surprise me at all if some portions of your lexer and parser really should be using some of Phobos' functions but isn't currently, because it's originally a port from C++. You should also make
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, March 08, 2012 22:03:12 Dmitry Olshansky wrote:
On 08.03.2012 11:48, Jonathan M Davis wrote:
A range is not necessarily a dynamic array, though a dynamic array is a
range. The lexer is going to need to take a range of dchar (which may or
may not be an array), and it's probably going to need to return a range
of tokens. The parser would then take a range of tokens and then output
the AST in some form or other - it probably couldn't be range, but I'm
not sure. And while the lexer would need to operate on generic ranges of
dchar, it would probably have to be special-cased for strings in a number
of places in order to make it faster (e.g. checking the first char in a
string rather than using front when it's known that the value being
checked against is an ASCII character and will therefore fit in a single
char - front has to decode the next character, which is less efficient).
Simply put, the decisison on decoding should belong to lexer. Thus
strings should be wrapped as input range of char, wchar dchar
respectively.
??? The normal way to handle this is to simply special-case certain
operations. e.g.
static if(Unqual!(isElementEncodingType!R) == char)
{ ... }
else
{ ... }
I'm not sure that wrapping char and wchar arrays in structs that treat them as
ranges of char or wchar is a good idea. At minimum, I'm not aware of anything
in Phobos currently working that way (unless you did something like that in
std.regex?). Everything either treats them as generic ranges of dchar or
special cases them. And when you want to be most efficient with string
processing, I would think that you'd want to treat them exactly as the arrays
of code units that they are rather than ranges - in which case treating them
as generic ranges of dchar in most places and then special casing certain
sections of code which can take advantage of the fact that they're arrays of
code units seems like the way to go. The lexer is then choosing when something
decodes, though the default is to decode, since it requires special-casing to
avoid it.
- Jonathan M Davis
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 2012-03-08 08:21, Zach the Mystic wrote: On Thursday, 8 March 2012 at 04:56:07 UTC, Jonathan M Davis wrote: If you took it from ddmd, then it's definitely going to have to be GPL. Now, there is interest in having a D parser and lexer in Phobos. I don't know if your version will fit the bill (e.g. it must have a range-based API), but we need one at some point. The original idea was to more or less directly port dmd's lexer and parser with some adjustments to the API as necessary (primarily to make it range-based). But no one has had the time to complete such a project yet (I originally volunteered to do it, but I just haven't had the time). When that project was proposed, Walter agreed to let that port be Boost rather than GPL (since he holds the copyright and the port would be going in Phobos, which uses boost). The problem with what you have (even if the API and implementation were perfect) is that it comes from ddmd, which had other contributors working on it. So, you would have to get permission from not only Walter but all of the relevant ddmd contributors. If you were able to _that_, and it could get passed the review process, then what you've done could be put into Phobos. But that requires that you take the time and effort to take care of getting the appropriate permissions, making sure that the API and implementation are acceptable for Phobos, and putting it through the Phobos review process. It would be great if you could do that though. - Jonathan M Davis This is great news. I was really worried that the license was etched in stone. I'll need help finding out who owns the code, plus legal advice if the process is more than just getting a simple confirmation email from each of the original authors. You have my blessing for the small changes I contributed with. -- /Jacob Carlborg
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 2012-03-08 09:20, Jonathan M Davis wrote: On Thursday, March 08, 2012 09:11:03 Jacob Carlborg wrote: On 2012-03-08 05:54, Jonathan M Davis wrote: On Thursday, March 08, 2012 03:12:48 Zach the Mystic wrote: On Thursday, 8 March 2012 at 01:43:26 UTC, Daniel Murphy wrote: Zach the Mysticreachminusthiszachgm...@dot.com wrote in message news:afqmbmvuvizvgfooe...@forum.dlang.org... I'll gladly put a license on it if the leaders of the community tell me which one to use ( Artistic, libpng, Boost ). Zach It will need to be the same license as the frontend (GPL/Artistic). It should be at the top of each c++ source file. It looks like the license is going to have to be GPL because it says so strictly in dmd's readme.txt. Somehow that license scares me, though. The Free Software Foundation seems like a very Orwellian institution to me. I hope it doesn't scare users away. If you took it from ddmd, then it's definitely going to have to be GPL. Now, there is interest in having a D parser and lexer in Phobos. I don't know if your version will fit the bill (e.g. it must have a range-based API), but we need one at some point. The original idea was to more or less directly port dmd's lexer and parser with some adjustments to the API as necessary (primarily to make it range-based). But no one has had the time to complete such a project yet (I originally volunteered to do it, but I just haven't had the time). When that project was proposed, Walter agreed to let that port be Boost rather than GPL (since he holds the copyright and the port would be going in Phobos, which uses boost). The problem with what you have (even if the API and implementation were perfect) is that it comes from ddmd, which had other contributors working on it. So, you would have to get permission from not only Walter but all of the relevant ddmd contributors. If you were able to _that_, and it could get passed the review process, then what you've done could be put into Phobos. But that requires that you take the time and effort to take care of getting the appropriate permissions, making sure that the API and implementation are acceptable for Phobos, and putting it through the Phobos review process. It would be great if you could do that though. - Jonathan M Davis It would be nice if the frontend written in D (which ever it will be) could be used by DMD. Then there wouldn't be any problems of being out of sync. Well, having it be easier to keep in sync is one of the reasons that it was originally proposed to simply port the lexer in dmd's frontend to D. But having it _be_ the frontend of dmd would be even better. I don't know how interested Walter is or isn't in that, but having it be a port of the current frontend would likely make convincing him easier than it would be if it were one written from scratch. - Jonathan M davis Exactly, that is what I'm thinking as well. Maybe it then can gradually be modified to better support an API useful for other things than just the compiler. Or building an higher level API on top of it that the compiler may not need to use. -- /Jacob Carlborg
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 08.03.2012 22:46, Jonathan M Davis wrote:
On Thursday, March 08, 2012 22:03:12 Dmitry Olshansky wrote:
On 08.03.2012 11:48, Jonathan M Davis wrote:
A range is not necessarily a dynamic array, though a dynamic array is a
range. The lexer is going to need to take a range of dchar (which may or
may not be an array), and it's probably going to need to return a range
of tokens. The parser would then take a range of tokens and then output
the AST in some form or other - it probably couldn't be range, but I'm
not sure. And while the lexer would need to operate on generic ranges of
dchar, it would probably have to be special-cased for strings in a number
of places in order to make it faster (e.g. checking the first char in a
string rather than using front when it's known that the value being
checked against is an ASCII character and will therefore fit in a single
char - front has to decode the next character, which is less efficient).
Simply put, the decisison on decoding should belong to lexer. Thus
strings should be wrapped as input range of char, wchar dchar
respectively.
??? The normal way to handle this is to simply special-case certain
operations. e.g.
static if(Unqual!(isElementEncodingType!R) == char)
{ ... }
Does isElementEncodingType aware of anything other then string/wstring?
else
{ ... }
I'm not sure that wrapping char and wchar arrays in structs that treat them as
ranges of char or wchar is a good idea. At minimum, I'm not aware of anything
in Phobos currently working that way (unless you did something like that in
std.regex?).
Well it's not that I'm insisting of _wrapping_ the arrays or some such
in general sense. And yes, I had some hard experience in std.regex with
UTF decoding and range design that doesn't exactly fits.
What I'm truly against is going overly generic and automatically
stomping on your performance. That being said the general design of
string ranges has unnessary pessimization already as it's popFront does
a UTF length lookup, identical operation is performed when decoding the
first codepoint (.front).
At any rate building lexer on top of ranges in current setting means
using abstraction that _hides_ decoding inside. That's a bad idea, it's
loosing a fight from the start. Why? Because in this case range can't
know if decoding is needed at this particular state of lexer or not, it
is generality that kills this by definition.
Yeah, in general auto-magically decoding ranges are OK, as long as the
stuff you do has cost much higher then decoding (~10 times would be
fine) or things that you strictly can't do otherwise. Lexer doesn't fall
into this criteria.
Everything either treats them as generic ranges of dchar or
special cases them. And when you want to be most efficient with string
processing, I would think that you'd want to treat them exactly as the arrays
of code units that they are rather than ranges - in which case treating them
as generic ranges of dchar in most places and then special casing certain
sections of code which can take advantage of the fact that they're arrays of
code units seems like the way to go.
Yeah, no arguing that. The thing is that lexer as a whole is precisely
one of these special cases. It's good as long as it's fast and that
requires more control then a generic input range of dchar.
Now, speaking outside of this specific problem.
Basically I would propose formalizing a kind of range that current
string/wstring is. And that is a VariableLengthEncoding range (VLE
range), a two in one - random access codeunit range and bidirectional
'codepoint' range. I've heard of attempts on this concept before, but
now with a use case at hand it could be become more important.
The problem is, I think, that current InputRange range is insufficent as
it requres to calculate length of first element twice: one time in front
and extra one in popFront.
--
Dmitry Olshansky
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Friday, March 09, 2012 00:54:48 Dmitry Olshansky wrote:
On 08.03.2012 22:46, Jonathan M Davis wrote:
On Thursday, March 08, 2012 22:03:12 Dmitry Olshansky wrote:
On 08.03.2012 11:48, Jonathan M Davis wrote:
A range is not necessarily a dynamic array, though a dynamic array is a
range. The lexer is going to need to take a range of dchar (which may or
may not be an array), and it's probably going to need to return a range
of tokens. The parser would then take a range of tokens and then output
the AST in some form or other - it probably couldn't be range, but I'm
not sure. And while the lexer would need to operate on generic ranges of
dchar, it would probably have to be special-cased for strings in a
number
of places in order to make it faster (e.g. checking the first char in a
string rather than using front when it's known that the value being
checked against is an ASCII character and will therefore fit in a single
char - front has to decode the next character, which is less efficient).
Simply put, the decisison on decoding should belong to lexer. Thus
strings should be wrapped as input range of char, wchar dchar
respectively.
??? The normal way to handle this is to simply special-case certain
operations. e.g.
static if(Unqual!(isElementEncodingType!R) == char)
{ ... }
Does isElementEncodingType aware of anything other then string/wstring?
No. It uses isNarrowString. So, what you'd end up doing is having the lexer
accept a generic range of dchar and then have specializations where
appropriate for narrow strings. Nothing in Phobos' string handling really
supports the idea of dealing with generic char or wchar ranges. It all
processes ranges of dchar and specializes on narrow strings where appropriate.
But is there really a use case for a generic range of char or wchar? I don't
know. In general, I really don't think that there is. When dealing with ranges
of characters, they're essentially always either strings or strings which have
been wrapped in other ranges (generally by calling some other range-based
function such as take or filter). And those range-based functions pretty much
inevitably need to treat the strings as ranges of dchar to do what they do
(potentially with specific optimizations for strings). They aren't designed to
operate on ranges of char or wchar, and the only reason to make them do so
would be if there were a use case where you needed a range of char or wchar
which was not an array. But they're all either arrays or wrapped arrays. So,
no such use case currently exists with Phobos, and I really question the
usefulness of trying to optimize on a generic range of char or wchar -
especially when many of the optimizations for arrays involve random access
ranges, and if you have a random access range of char or wchar, I _really_
question that it would ever be anything other than an array.
So, I'd advise against trying to operate on ranges of char or wchar and just
stick to operating on ranges of dchar with optimizations for narrow strings
where appropriate.
Now, speaking outside of this specific problem.
Basically I would propose formalizing a kind of range that current
string/wstring is. And that is a VariableLengthEncoding range (VLE
range), a two in one - random access codeunit range and bidirectional
'codepoint' range. I've heard of attempts on this concept before, but
now with a use case at hand it could be become more important.
There has been some talk of VLE ranges but really only with regards to the
fact that strings are a case of that. Nothing has been done to generalize it.
It may be something that should be looked into, but until we've formalized
that, I don't think that something like the lexer should be built around the
idea. It would be safer to stick with what we've been doing - operating on
ranges of dchar and special-casing for narrow strings where appropriate. If
need be, it should be possible to adjust it to use VLEs later.
The problem is, I think, that current InputRange range is insufficent as
it requres to calculate length of first element twice: one time in front
and extra one in popFront.
Perhaps an optional function should be added to input ranges which both
returns and front and pops it. But VLE ranges such as narrow strings are
probably the only ones which would really care, and we can already special
case for strings, so it would probably only be of real value for general VLEs.
However, since VLEs would arguably be a new range type, they could just
implement the new function, and anything which special-cases VLEs can take
advantage of it, while they still work just fine as input ranges. We could even
add a free function which both pops and returns front which uses front and
popFront for most ranges and the new function for VLEs, so you can code with
that free function in cases where you intend to both take front and pop it off
without caring about what type
Re: D to Javascript converter (a hacked up dmd)
Am 01.03.2012, 17:29 Uhr, schrieb Robert Clipsham rob...@octarineparrot.com:
Interesting idea:
version(JavaScript) asm
{
/* Well... it's not really asm, but it's
as close as you could get with a javascript backend :p */
document.write(Oh look, inline javascript D-:);
}
Perhaps it would be better to have a dedicated function for that though.
How about:
pragma(js)
{
document.write(Oh look, inline javascript D-:);
}
Re: Enhanced D syntax highlighting for Sublime Text 2
On Wed, 07 Mar 2012 20:59:36 +0200, Alex Rønne Petersen xtzgzo...@gmail.com wrote: https://github.com/alexrp/st2-d I plan to have it merged into ST2 proper if I can somehow get in touch with the dev(s)... Thanks, and good luck with the merge. I find ST2 the first text editor that is truly beautiful. -- Byakkun
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, 8 March 2012 at 19:36:32 UTC, Jacob Carlborg wrote: This is great news. I was really worried that the license was etched in stone. I'll need help finding out who owns the code, plus legal advice if the process is more than just getting a simple confirmation email from each of the original authors. You have my blessing for the small changes I contributed with. Great!
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On Thursday, 8 March 2012 at 07:49:57 UTC, Jonathan M Davis wrote: Regardless, you need to familiarize yourself with ranges if you want to get the lexer and parser ready for inclusion in Phobos. I have to admit that I don't currently feel competent to do this work. I'm too green. But I do think that the program is already very close to what is needed. I also would assume that those experienced with dmd's C++ incarnation will find themselves on rather familiar soil if they set to work on the D version, so that might speed things up a little if they also know about ranges.
Re: D in Academia
On Saturday, 3 March 2012 at 19:02:23 UTC, Chuck Allison wrote: FYI: TDPL is a required text for CS 4450, Analysis of Programming Languages, at Utah Valley University starting Fall 2012. We'll study ML and D (and Prolog if time allows). Slightly off topic digression: Which ML? I ask as an OCaml partisan (and D fan!) who will obviously suggest that you go with that language, since it is probably the more widely used ML variant. -- Brian
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 09.03.2012 1:12, Jonathan M Davis wrote:
On Friday, March 09, 2012 00:54:48 Dmitry Olshansky wrote:
On 08.03.2012 22:46, Jonathan M Davis wrote:
On Thursday, March 08, 2012 22:03:12 Dmitry Olshansky wrote:
On 08.03.2012 11:48, Jonathan M Davis wrote:
A range is not necessarily a dynamic array, though a dynamic array is a
range. The lexer is going to need to take a range of dchar (which may or
may not be an array), and it's probably going to need to return a range
of tokens. The parser would then take a range of tokens and then output
the AST in some form or other - it probably couldn't be range, but I'm
not sure. And while the lexer would need to operate on generic ranges of
dchar, it would probably have to be special-cased for strings in a
number
of places in order to make it faster (e.g. checking the first char in a
string rather than using front when it's known that the value being
checked against is an ASCII character and will therefore fit in a single
char - front has to decode the next character, which is less efficient).
Simply put, the decisison on decoding should belong to lexer. Thus
strings should be wrapped as input range of char, wchar dchar
respectively.
??? The normal way to handle this is to simply special-case certain
operations. e.g.
static if(Unqual!(isElementEncodingType!R) == char)
{ ... }
Does isElementEncodingType aware of anything other then string/wstring?
No. It uses isNarrowString. So, what you'd end up doing is having the lexer
accept a generic range of dchar and then have specializations where
appropriate for narrow strings. Nothing in Phobos' string handling really
supports the idea of dealing with generic char or wchar ranges. It all
processes ranges of dchar and specializes on narrow strings where appropriate.
The concept that *only* strings need special casing is broken. I recall
somebody already stomped on this: i.e. any range that returns char (a
wrapper range, over say memory-mapped file) passes by all the intricate
special casing that does decoding of std.algorithm and friends. So to
put it simply there is no way to tap into this *decoding by default*
infrastructure.
But is there really a use case for a generic range of char or wchar? I don't
know. In general, I really don't think that there is.
Memory mapped file wrapper is one, it's just from the top of my head.
There could be plenty of them, one needs just to look. 'I don't
know' is not a solid argument, sorry.
When dealing with ranges
of characters, they're essentially always either strings or strings which have
been wrapped in other ranges (generally by calling some other range-based
function such as take or filter). And those range-based functions pretty much
inevitably need to treat the strings as ranges of dchar to do what they do
(potentially with specific optimizations for strings). They aren't designed to
operate on ranges of char or wchar, and the only reason to make them do so
would be if there were a use case where you needed a range of char or wchar
which was not an array. But they're all either arrays or wrapped arrays. So,
no such use case currently exists with Phobos, and I really question the
usefulness of trying to optimize on a generic range of char or wchar -
especially when many of the optimizations for arrays involve random access
ranges, and if you have a random access range of char or wchar, I _really_
question that it would ever be anything other than an array.
And that is problem, if you fail to see why we need to stop pretending
that all char/wchar ranges are arrays, then I failed somewhere. In the
same vane one would argue that there is no other random access range but
array, yet there is. For instance if we explore containers there could
be Tries, Dequeues and whatnot of char/wchar with their respective ranges.
So, I'd advise against trying to operate on ranges of char or wchar and just
stick to operating on ranges of dchar with optimizations for narrow strings
where appropriate.
Probably the fact that in lexer it's not 'some place for optimizations,
it's the whole thing' was missed. That's why I'm looking for more or
less generic yet efficient way.
Now, speaking outside of this specific problem.
Basically I would propose formalizing a kind of range that current
string/wstring is. And that is a VariableLengthEncoding range (VLE
range), a two in one - random access codeunit range and bidirectional
'codepoint' range. I've heard of attempts on this concept before, but
now with a use case at hand it could be become more important.
There has been some talk of VLE ranges but really only with regards to the
fact that strings are a case of that. Nothing has been done to generalize it.
It may be something that should be looked into, but until we've formalized
that, I don't think that something like the lexer should be built around the
idea. It would be safer to stick with what we've been doing - operating on
ranges of dchar and
Re: Poll of the week: main OS and compiler
On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote: Walter, how big is it really? Small enough to be done as, say, a gsoc project? Would you be interested in mentoring such a project? I don't know whether it would really be a problem from a legal (Google) point of view, but having a GSoC student work on non-Open Source software seems strange at least. David
Re: dereferencing null
On 06/03/12 17:05, Sean Kelly wrote:
On Mar 6, 2012, at 3:14 AM, Don Clugstond...@nospam.com wrote:
Responding to traps is one of the very few examples I know of, where Windows
got it completely right,
and *nix got it absolutely completely wrong. Most notably, the hardware is
*designed* for floating point traps to be fully recoverable. It makes perfect
sense to catch them and continue.
But unfortunately the *nix operating systems are completely broken in this
regard and there's nothing we can do to fix them.
Does SEH allow recovery at the point of error like signals do?
Yes, it does. It really acts like an interrupt. You can, for example,
modify registers or memory locations, then perform the equivalent of an
asm { iret; }, so that you continue at the next instruction. Or, you can
pass control to any function, after unwinding the stack by any number of
frames you chose. And, you regain control if any other exception occurs
during the unwinding, and you're given the chance to change strategy at
that point.
An SEH handler behaves a bit like setjmp(), it's not a callback.
Most importantly, in comparison to Posix, there are NO LIMITATIONS about
what you can do in an SEH exception handler. You can call any function
you like.
The documentation is terrible, but it's really a beautiful design.
Sometimes I think it would be enough if the Posix spec were worded in
a way that allowed exceptions to be thrown from signal handlers.
I think that would be difficult to allow. Some of the restrictions seem
to be quite fundamental. (Otherwise, I'm sure they would have got rid of
them by now!)
Re: Poll of the week: main OS and compiler
On 8 March 2012 00:21, Jonathan M Davis jmdavisp...@gmx.com wrote: On Wednesday, March 07, 2012 23:07:11 Mars wrote: On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote: Personally, I just want to be able to link like a normal windows developer. My code is C/C++, built with VC, and I want to link my D app against those libs using the VC linker, and debug with Visual Studio. This is the workflow I think the vast majority of Windows devs will expect, and it sounds simple enough. This is the only thing standing between me using D for any major projects, and just experimenting with the language for evaluation, or just academic interest. 64bit is far less important to me personally, VisualC linker compatibility is the big one. I just want to link against my C code without jumping through lots of hoops. That's exactly my problem... and although I love D, these hurdles made me take a step back, to C++, while I wait for this to change, so I can finally use D efficiently. I'm sure this isn't a trivial task, but the problematic isn't new after all. Why hasn't it been addressed yet? In my eyes this should be a top priority, to make it easier for new users to get into D. Till this poll I actually believed the problem was that D isn't used much by Windows users. I don' think that Walter really views it as much of a problem - or if he does, he didn't used to. Remember that he's used to an environment where he doesn't use Visual Studio or Microsoft's C++ compiler. And his customers use dmc just like he does (since they're his customers), so many of the people that he interacts with in the C/C++ world are not necessarily particularly Microsoft- centric on Windows. Add to that the enormous task that it is to actually make dmd work with COFF or 64-bit or anything of the sort on Windows, and it's no wonder that it hasn't happened yet. To be fair, there are plenty of other things that have needed to be done, and what we have for Windows does work, even if it's suboptimal. So, it's not all that unreasonable that the issue would be put off as long as it has been. And Walter _has_ been slowing working on porting optlink to C (the fact that it's written in assembly makes it really fast but hard to maintain and change), which would make it possible to then start porting stuff to 64-bit and considering COFF and stuff like that. Is it possible to just fix the compiler to output COFF objects *without* touching optlink at all? I'm not interested in using optlink with this feature, I intend to link with Visual Studio, that's the whole point. So ignoring optlink, that's a major slice of work taken out of the equation... Maybe it would be nice to support optlink in future, but it seems the priority is backwards. I expect that we'll get there eventually, but there's so much to do, and this particular issue is not only hard, but there's pretty much only one person currently qualified to do it, so it hasn't happened yet. - Jonathan M Davis
Re: Poll of the week: main OS and compiler
On Thursday, March 08, 2012 11:12:01 Manu wrote: Is it possible to just fix the compiler to output COFF objects *without* touching optlink at all? I have no idea. In principle, I would think so, but I don't know. But dmd would have to be altered so that you could choose the object format rather than being simply switched over to COFF regardless. Ideally, it would be modular enough to be able to make it output any format you like with plugins or somesuch, but I have no idea how it's designed. And therein is the largest problem regardless. Walter is probably the only person who knows the backend well enough to do anything like this. So, regardless of what the situation with optlink is, it's almost certainly going to require Walter, who's busy with plenty of other stuff which is also very important. If someone could make the changes themselves and create a pull request for it, then we could probably get COFF, but that would require someone knowledgeable enough to do that, and I don't think that anyone other than Walter really is. If someone other than Walter is going to do it, then they've got a lot to learn, and no one has taken the time to do that. - Jonathan M Davis
Re: Poll of the week: main OS and compiler
On Thursday, March 08, 2012 09:45:34 David Nadlinger wrote: On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote: Walter, how big is it really? Small enough to be done as, say, a gsoc project? Would you be interested in mentoring such a project? I don't know whether it would really be a problem from a legal (Google) point of view, but having a GSoC student work on non-Open Source software seems strange at least. I though that GSoC had a list of licenses which were acceptable for GSoC projects - all of which are open source license of one variety or another. - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.214.1331187413.4860.digitalmar...@puremagic.com...
On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:
Ary Manzana a...@esperanto.org.ar wrote in message
news:jj94mb$1i7v$1...@digitalmars.com...
Here's something I wrote today:
parent_ids = results.map{|x|
x['_source']['parent_ids']}.flatten.uniq.compact
Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
When you format it like that (that is to say, when you *don't* format
it),
yea, it's unreadable. Which is why I do such things like this:
parent_ids =
results
.map{|x| x['_source']['parent_ids']}
.flatten.uniq
.compactHash[
Site.find(parent_ids).map{|x| [x.id, x]}
]
I actually tend to find code like that hard to read, because all of the
operations are inside out in comparison to normal. But since the only
difference between his example and yours is the formatting, I agree yours
is
easier to read. Still, I'd much prefer if such code didn't use UFCS, since
I
find it much harder to read that way. It's just so backwards.
Aside from the problems of excess paren nesting, I tend to think this is
backwards:
foo(bar(baz(x+2)))
...because the order it's read/written is the complete opposite of the order
of exectution. First x+2 is evaluated, then baz, then bar, then foo.
Ie, it's executed right-to-left even though you read/write it left-to-right.
Completely backwards. Contrast that with:
(x+2).baz().bar().foo()
...which we may be less accustomed to (unless you think of it like bash
piping), but in addition to the decrease in nesting, it's written and read
in the *same* order as exection: left to right. This also means that it's no
longer the complete reverse of statements which are (sensibly)
left-to-right:
y = x+2; baz(); bar(); foo();
If I were writing code in Arabic, I would probably like
foo(bar(baz(x+2))). (I would also wonder What a minute, when did I learn
Arabic? How did I manage to learn a langauge without even knowing? This is
really weird! But fun. Wheee!!)
Re: Arbitrary abbreviations in phobos considered ridiculous
On 2012-03-07 19:40, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message news:jj755f$r7u$1...@digitalmars.com... On 2012-03-07 04:46, Nick Sabalausky wrote: Adam D. Ruppedestructiona...@gmail.com wrote in message news:bwqkuqhyiygvgqswi...@forum.dlang.org... On Wednesday, 7 March 2012 at 03:24:23 UTC, Jonathan M Davis wrote: I don't understand this complaint at all. curr is an incredibly common abbreviation for current. Is it your *first* choice? In the general case, it frequently is for me. In the specific case of Clock.curr(ent)?Time, I'm equally happy either way. Although I agree with whoever it was (Brad?) that said Clock.now() would be even better. Yeah, Clock.now() would be good and Data.today() as well. I dunno, on the second one, I think I'd prefer Date.today() ;) (Nyuk nyuk nyuk) Hehe, missed that :) -- /Jacob Carlborg
Re: Arbitrary abbreviations in phobos considered ridiculous
On 2012-03-07 19:50, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message news:jj74p4$n9r$3...@digitalmars.com... On 2012-03-07 03:18, Nick Sabalausky wrote: Jonathan M Davisjmdavisp...@gmx.com wrote in message news:mailman.110.1331077432.4860.digitalmar...@puremagic.com... On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote: Nope, apparently, I meant dur. Ridiculous. A Duration needs to be constructed with a template, and duration!hours(13), duration!seconds(44), etc. is painfully long when used in expressions. So, it was shortened to dur. I don't know of any other abbreviation which would make sense. This is exactly why dur never bothered me. Now that Adam's brought it up, I can see how it can be considered bad, but at the same time 'duration!seconds(44)' is a rather long to way to refer to x number of seconds. But, I'm thinking this whole dur vs duration matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the dur or duration for anyway? I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done: alias dur!years years; alias dur!months months; alias dur!weeks weeks; alias dur!days days; alias dur!hours hours; alias dur!minutes minutes; alias dur!seconds seconds; alias dur!msecs msecs; alias dur!usecs usecs; alias dur!hnsecs hnsecs; And then we have the brevity issue solved (and in fact, improved over dur), so then dur can (and should) change to duration without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit. I agree, adding these aliases would be a good idea. I like that so many people agree with this. But I do want to point out again, just in case anyone missed it, that I'm hoping it would *actually* be: alias duration!years years; alias duration!months months; etc... That's what I was hoping for as well. Since the aliases themselves mitigate the need for duration itself to be shortened. Course, I can still live with just 'alias dur!years years;..etc...'. The *main* thing is that we can just do hours(5)...(or heck, once UFCS finally gets fixed: 5.hours) That would be so nice. Actually UFCS seems to have been merged now: https://github.com/D-Programming-Language/dmd/commit/b7742f7a733ff73d364c6ed54af70d875d7e911b -- /Jacob Carlborg
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thursday, March 08, 2012 04:26:11 Nick Sabalausky wrote: Aside from the problems of excess paren nesting, I tend to think this is backwards: foo(bar(baz(x+2))) Yes, but that's how functions normally work, so flipping it around _is_ backwards from the normal, even if some people find it easier to understand. And I've written enough in functional languages that flipping it around just seems _really_ backwards to me. At this point, I always have a harder time reading code when someone insists on chaining UFCS calls rather than using normal function calls. But obviously YMMV. - Jonathan M Davis
Re: Poll of the week: main OS and compiler
On Thursday, 8 March 2012 at 09:25:19 UTC, Jonathan M Davis wrote: On Thursday, March 08, 2012 09:45:34 David Nadlinger wrote: On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote: Walter, how big is it really? Small enough to be done as, say, a gsoc project? Would you be interested in mentoring such a project? I don't know whether it would really be a problem from a legal (Google) point of view, but having a GSoC student work on non-Open Source software seems strange at least. I though that GSoC had a list of licenses which were acceptable for GSoC projects - all of which are open source license of one variety or another. - Jonathan M Davis That's his point; the backend isn't open source.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky a@a.a wrote: British English may be the more official English, with American English as a mere variation ... In one sense, American English is often a sort of abbreviated version in which seemingly superfluous letters are omitted. But in other cases, it more accurately reflects pronunciation (colorize verses colourise). Speaking of...do the British actually pronounce colour with a u sound? If not, I'd argue color really is a better spelling ;) (Not as good as kulr, but whatever) I'm not sure about British pronunciation (I'm Australian) but 'color' is said as kull-ore' and 'colour' is said like 'kull-er' or even 'kull-ah'. But my point, a part from being a bit whimsical, was that we can even have disagreements over fully spelt (spelled?) words let alone abbreviations (ironically that is word that *needs* shortening) so I think the criteria for publicly exposed function names should hinge on the consistency of naming conventions rather than focus on abbrv. vs. FullySpelledOutWords. -- Derek Parnell Melbourne, Australia
Re: Arbitrary abbreviations in phobos considered ridiculous
On 03/08/2012 03:14 AM, Ary Manzana wrote:
Here's something I wrote today:
parent_ids = results.map{|x|
x['_source']['parent_ids']}.flatten.uniq.compact
Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
Or I could have written:
Hash[
Site.find(
results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
).map{|x| [x.id, x]}
]
No abbreviation at all,
uniq.
Re: Arbitrary abbreviations in phobos considered ridiculous
On 03/08/2012 03:20 AM, Kapps wrote: On Wednesday, 7 March 2012 at 19:12:25 UTC, H. S. Teoh wrote: Supporting stuff like 5.hours will introduce additional complications to D's lexical structure, though. The lexer will have to understand it as (int:5)(.)(ident:hours) rather than (float:5.)(ident:hours). And then if you actually *wanted* a float, you'd have another ambiguity: 5..hours could mean (float:5.)(.)(ident:hours) or (int:5)(..)(hours). And 5.0.hours just looks... weird. T Actually, Kenji's pull request for UFCS already takes care of this. Things like 5. aren't allowed, nor is 5.f; a number has to follow the decimal. So 5.f would invoke UFCS function f with the integer 5. I believe this change is already merged, though the rest of the UFCS pull request isn't unfortunately. 5. is still allowed.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thu, 08 Mar 2012 10:21:00 -, Derek ddparn...@bigpond.com wrote: On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky a@a.a wrote: British English may be the more official English, with American English as a mere variation ... In one sense, American English is often a sort of abbreviated version in which seemingly superfluous letters are omitted. But in other cases, it more accurately reflects pronunciation (colorize verses colourise). In Britain (where I live) there are people to pronounce the 'u' in colour, and colourise. The difference is subtle, and I've found many people simply cannot hear it. It's the reason many people (and the brash American tourist stereotype springs to mind - but there are people the world over) have trouble learning and speaking a foreign language, they cannot hear where they're going wrong (or they don't care - which is a different issue). I think my own ear is able to hear some, perhaps a good number of the subtleties, for example it was good enough that a local Colombian thought I was myself Colombian after having spoken a few short (uncomplicated, as my Spanish is basic at best) sentences with them. Speaking of...do the British actually pronounce colour with a u sound? If not, I'd argue color really is a better spelling ;) (Not as good as kulr, but whatever) I'm not sure about British pronunciation (I'm Australian) but 'color' is said as kull-ore' and 'colour' is said like 'kull-er' or even 'kull-ah'. This is why Australians and New Zealanders (myself) should not be asked how to pronounce words, our vowels are all either 'wrong' or missing completely. :p Back to the main topic, being from NZ, where British English is the standard, I prefer it to American. But, I can easily adapt to whichever is used in a body of code. Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: dereferencing null
On Thu, 08 Mar 2012 03:58:22 -0500, Don Clugston d...@nospam.com wrote:
On 06/03/12 17:05, Sean Kelly wrote:
On Mar 6, 2012, at 3:14 AM, Don Clugstond...@nospam.com wrote:
Responding to traps is one of the very few examples I know of, where
Windows got it completely right,
and *nix got it absolutely completely wrong. Most notably, the
hardware is *designed* for floating point traps to be fully
recoverable. It makes perfect sense to catch them and continue.
But unfortunately the *nix operating systems are completely broken in
this regard and there's nothing we can do to fix them.
Does SEH allow recovery at the point of error like signals do?
Yes, it does. It really acts like an interrupt. You can, for example,
modify registers or memory locations, then perform the equivalent of an
asm { iret; }, so that you continue at the next instruction. Or, you can
pass control to any function, after unwinding the stack by any number of
frames you chose. And, you regain control if any other exception occurs
during the unwinding, and you're given the chance to change strategy at
that point.
An SEH handler behaves a bit like setjmp(), it's not a callback.
Most importantly, in comparison to Posix, there are NO LIMITATIONS about
what you can do in an SEH exception handler. You can call any function
you like.
The documentation is terrible, but it's really a beautiful design.
Sometimes I think it would be enough if the Posix spec were worded in
a way that allowed exceptions to be thrown from signal handlers.
I think that would be difficult to allow. Some of the restrictions seem
to be quite fundamental. (Otherwise, I'm sure they would have got rid of
them by now!)
IIRC, SEH is patented...
-Steve
Re: inout and function/delegate parameters
On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr timon.g...@gmx.ch wrote: On 03/07/2012 11:37 PM, Stewart Gordon wrote: On 07/03/2012 15:41, Steven Schveighoffer wrote: snip In fact, I think this is valid D code: int i; const int *pi = i; int *p = cast()pi; *p = 5; // legal because I know this points at i, and i is really mutable cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works. It is not legal code. I did not point it out because it was clear what was meant. cast() only casts away the top level of modifiers. It is perfectly safe except for class objects. If it's not legal code, then how is implicitly casting away inout during function execution legal code? Isn't this the same thing? -Steve
Gentoo ebuilds (was: DustMite updated)
Am 04.03.2012, 19:39 Uhr, schrieb Chad J chadjoan@__spam.is.bad__gmail.com: DMD32 D Compiler v2.057 on Gentoo Linux If it's because my compiler is a version behind, then don't worry about it too much. I haven't updated because issue 5278 (http://d.puremagic.com/issues/show_bug.cgi?id=5278) makes it a pain for me to upgrade the dmd. If you find any problems with the ebuilds, don't hesitate write an email to me for DMD2 or Julian hasufell Ospald for DMD1. (See http://overlays.gentoo.org/proj/sunrise/browser/reviewed/dev-lang/dmd/ChangeLog ) for the email address. They are taken from the discontinued d-overlay and updated to meet Portage ebuild writing standards. We may be able to sort out some Gentoo specific issues for already released versions of DMD via patches. I also keep the three most recent releases in the tree, so you can downgrade in case of problems. -- Marco
Re: Arbitrary abbreviations in phobos considered ridiculous
On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana a...@esperanto.org.ar
wrote:
The problem is not mistaking it with something else. The problem is when
you want to write it. In Ruby my mind works like this:
Mind: How would I get a span for 5 seconds?
Mind: Let's try 5.seconds
Mind: Wow, it works!
I'm trying to remember cases when I just wrote what my mind thought it
was correct and I was *so* surprised it worked out of the box in Ruby.
Like writing array.last, and get it to work, instead of
array[array.length - 1]. But in D, from the docs
(http://dlang.org/arrays.html )
bar[$-1] // retrieves last element of the array
I read: bar dollar minus one wait what??
array.back;
http://dlang.org/phobos/std_array.html#back
This is the issue with intuition. It's easy to say, hey I guessed
right in Ruby! Ruby must be more intuitive!. But if you were someone
who knew the range interfaces, wouldn't you try array.back in Ruby and say
well, obviously D is more intuitive, it knew what I wanted without even
looking up the docs!
You are never going to come up with something that's *perfectly* intuitive
for everyone in every situation.
Now, in D I try:
5.seconds
and it doesn't work. I have to write this very unintuitive:
dur!minutes(5)
Was it really necessary to implement it that way?
No, nothing is ever necessary to implement a certain way. But there are
practical concerns. For example, assuming UFCS worked in D, you *could*
possibly do 5.seconds. However, this means you need a module-level
function:
Duration seconds(long n) {...}
But the way D's overload resolution works, this precludes having 5.seconds
work, and also having a member named 'seconds' in your class/struct.
The nice thing about dur!seconds is that only one module-level symbol is
introduced (dur), and it's unlikely to conflict with local symbols
It may not be as intuitive, but it's certainly readable, and not too
verbose to type.
-Steve
Re: Automatic minimally sized SELECT clauses in SQL using D templates.
Am 04.03.2012, 19:58 Uhr, schrieb Chad J chadjoan@__spam.is.bad__gmail.com: I'd almost be sort of surprised if someone here hasn't thought of this already, but I'll drop it out here anyways. This is a proof-of-concept program I wrote to do a query with the convenience of a SELECT * FROM ..., but without actually pulling every column in the database. Yes, there is an existing D library that use CTFE to generate lazy evaluated data structures from SQL queries. And although I was very impressed by the solution and how it integrated with foreach I forgot the name and URL. (Haven't been using SQL since a while.) Maybe someone else remembers. I usually find it helpful to look at other peoples' solution to the same problem, since D offers so many concepts and you easily miss some good stuff.
How to design date/time libraries (was: Arbitrary abbreviations in phobos considered ridiculous)
On 08/03/2012 02:56, Jonathan M Davis wrote: On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote: On 07/03/2012 08:10, Jacob Carlborg wrote: snip Yeah, Clock.now() would be good and Data.today() as well. My utility library has, for consistency, DateValue.now, TimeValue.now and DateTime.now. I specically avoided giving a way to get the time with any type other than SysTime (and TickDuration for using a monotonic clock), because I believe that it leads to incorrect behavior. Any time that you're dealing with the system clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are for when you need the date and/or time but don't care about what absolute time it's associated with in the real world. Treating DateTime as corresponding to a specific point in time is just going to cause problems, because it has no time zone. snip TimeValue and DateTime in my library always store the time in UTC. It uses a global variable for time zone. But a LocalTime could be added to the mix. This would be used to hold a time that, when combined with a date, will become a DateTime set according to the correct time zone. Interestingly, SQL has DATE - just a date, simple as that TIME - a time of day in unspecified time zone TIMETZ - a time of day with time zone specified TIMESTAMP - a date/time combination in unspecified time zone TIMESTAMPTZ - an absolute instant in time, which can be constructed and examined according to the system time zone Notice how different TIMETZ and TIMESTAMPTZ are, even though TZ abbreviates WITH TIME ZONE in both cases. Moreover, system time zones (in at least some SQL implementations) include DST rules, whereas the zone stored in a TIMETZ is just a UTC offset. In my scheme: - DateValue corresponds to DATE - TimeValue corresponds to a TIMETZ with the zone set as UTC - DateTime corresponds to TIMESTAMPTZ - LocalTime, if it were added, would correspond to TIME I'd also like to add DST handling to my library, but it'll take thinking about. I'm not sure what OS APIs have in the way of retrieving the DST rules for the locale. Though I have just discovered GetDynamicTimeZoneInformation in the Windows API - I'll investigate it later. Stewart.
Phoronix Compiler Testing
I just read about this and thought it might be useful. http://www.phoronix.com/scan.php?page=news_itempx=MTA2NzU
[OT] American versus British spelling and pronunciation (was: Arbitrary abbreviations in phobos considered ridiculous)
On 08/03/2012 11:04, Regan Heath wrote: On Thu, 08 Mar 2012 10:21:00 -, Derek ddparn...@bigpond.com wrote: On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky a@a.a wrote: British English may be the more official English, with American English as a mere variation ... In one sense, American English is often a sort of abbreviated version in which seemingly superfluous letters are omitted. But in other cases, it more accurately reflects pronunciation (colorize verses colourise). Indeed. Sometimes the British spelling is more logical (judgement versus judgment). Sometimes the American spelling is more logical (skeptical versus sceptical). In Britain (where I live) there are people to pronounce the 'u' in colour, and colourise. The difference is subtle, and I've found many people simply cannot hear it. snip I'm finding it hard to figure how someone would pronounce the o and u in colour separately. But to me, it's just the same phoneme as found in most -er and -or words. Stewart.
Re: Arbitrary abbreviations in phobos considered ridiculous
I feel compelled to point out that there is no such thing as British English. There is English, the written language with all its archaic spellings and there are many spoken dialects, the most formal of which is RP (Received Pronunciation) sometimes called The Queen's English (even though she is German). If we went to the effort of re-spelling words to match how they were spoken, then we would just end up with multiple accepted spellings (and some new letters), or a nation of 1920s radio newscasters, neither of which appeals to me. As it is, the archaic spellings help to make words more visually distinct, after all, we have some words that are spoken the same but spelled differently (and vice versa ). As for identifiers and abbreviations, as long as they are sufficiently visually distinct, I'd be happy. I tolerate USian spellings as much as non-English speaking programmers do, because I see it as an accepted Programmer's English. Secondly, D has its the obvious solution is the right solution philosophy. so the right identifiers should also be the obvious ones, but they should also be short especially when used frequently. Longer identifiers should be used sparingly, but are useful to convey subtleties such as different side effects and of course, to make non-safe code stand out. A...
Re: [OT] American versus British spelling and pronunciation (was: Arbitrary abbreviations in phobos considered ridiculous)
On 9 March 2012 01:23, Stewart Gordon smjg_1...@yahoo.com wrote: On 08/03/2012 11:04, Regan Heath wrote: On Thu, 08 Mar 2012 10:21:00 -, Derek ddparn...@bigpond.com wrote: On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky a@a.a wrote: British English may be the more official English, with American English as a mere variation ... In one sense, American English is often a sort of abbreviated version in which seemingly superfluous letters are omitted. But in other cases, it more accurately reflects pronunciation (colorize verses colourise). Indeed. Sometimes the British spelling is more logical (judgement versus judgment). Sometimes the American spelling is more logical (skeptical versus sceptical). In Britain (where I live) there are people to pronounce the 'u' in colour, and colourise. The difference is subtle, and I've found many people simply cannot hear it. snip I'm finding it hard to figure how someone would pronounce the o and u in colour separately. But to me, it's just the same phoneme as found in most -er and -or words. Stewart. Being British means that I do notice the differences in pronunciation, I've pretty much done the opposite to Reagan, gone from England to NZ. I tend to get frustrated when I can't even correct pronunciation because nobody can hear the difference! -- James Miller
Re: Automatic minimally sized SELECT clauses in SQL using D templates.
On 03/08/2012 07:00 AM, Marco Leise wrote: Am 04.03.2012, 19:58 Uhr, schrieb Chad J chadjoan@__spam.is.bad__gmail.com: I'd almost be sort of surprised if someone here hasn't thought of this already, but I'll drop it out here anyways. This is a proof-of-concept program I wrote to do a query with the convenience of a SELECT * FROM ..., but without actually pulling every column in the database. Yes, there is an existing D library that use CTFE to generate lazy evaluated data structures from SQL queries. And although I was very impressed by the solution and how it integrated with foreach I forgot the name and URL. (Haven't been using SQL since a while.) Maybe someone else remembers. I usually find it helpful to look at other peoples' solution to the same problem, since D offers so many concepts and you easily miss some good stuff. Cool, thanks for pointing that out.
Re: Poll of the week: main OS and compiler
David Nadlinger s...@klickverbot.at wrote in message news:refqfgvqmhafcmelj...@forum.dlang.org... On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote: Walter, how big is it really? Small enough to be done as, say, a gsoc project? Would you be interested in mentoring such a project? I don't know whether it would really be a problem from a legal (Google) point of view, but having a GSoC student work on non-Open Source software seems strange at least. David Didn't think of that... I'm not sure what the license on the object generation code is, the files are not in the backend folder but they are conceptually part of the backend, and not useful to other compilers like the frontend is.
Re: Arbitrary abbreviations in phobos considered ridiculous
On 2012-03-07 23:55, Stewart Gordon wrote: On 06/03/2012 16:38, Adam D. Ruppe wrote: One of the stumbling blocks on using std.datetime is how many bizarre abbreviations it has. auto time = Clock.currentTime(); // bzzt, wrong if(time - something duration!hours(4)) // bzzt, wrong writeln(time.toISOExtendedString()); // bzzt, wrong, but this used to work! snip The mention of this one reminds me of another issue: capitalisation consistency. It would be nice to standardise whether acronyms/initialisms occurring within names have just the first letter or all letters capitalised. I'm thinking best is to treat them as words and therefore capitalise just the first letter. Though I've been known to do otherwise in the past. But it's confusing enough that there are still many functions in Phobos whose names are all lowercase when they should be camelCase. The Java API is in a mess in this respect: http://www.mindprod.com/jgloss/inconsistencies.html We'd have no trouble avoiding this if only Phobos was designed to be free of such inconsistencies from its beginning. Stewart. I would go with strict camlecase. So if a identifier has an acronym in the middle of the name, I would only capitalize the first letter. If the identifier starts with an acronym, I would not capitalize any of the letters in the acronym. auto isoExtendedString = time.toIsoExtendedString() -- /Jacob Carlborg
Re: AA implementation question
FWIW Steven's dcollections has a hash implementation, you could take a look (it's Boost-licensed): http://www.dsource.org/projects/dcollections
Re: AA implementation question
By hash I mean map/AA.
Re: Arbitrary abbreviations in phobos considered ridiculous
On 2012-03-08 02:22, Stewart Gordon wrote: On 07/03/2012 08:10, Jacob Carlborg wrote: snip Yeah, Clock.now() would be good and Data.today() as well. My utility library has, for consistency, DateValue.now, TimeValue.now and DateTime.now. Stewart. Cool. Why the Value suffix? -- /Jacob Carlborg
Re: dereferencing null
I think what Chad is looking for is a BlackHole/WhiteHole equivalent which doesn't need abstract functions but which figures out all the methods of a class at compile time and creates a subclass that throws/does nothing on method invocation. An 'alias this' field would be used that is default-initialized with this sentry object. I don't know why we don't have __traits(allFunction). We have 'getVirtualFunctions' but it requires a function name, but using allMembers to filter out function names is damn difficult if you ask me. I've never had an easy time interacting with __traits.
Re: Poll of the week: main OS and compiler
Manu turkey...@gmail.com wrote in message news:mailman.223.1331197934.4860.digitalmar...@puremagic.com... On 8 March 2012 00:21, Jonathan M Davis jmdavisp...@gmx.com wrote: Is it possible to just fix the compiler to output COFF objects *without* touching optlink at all? I'm not interested in using optlink with this feature, I intend to link with Visual Studio, that's the whole point. So ignoring optlink, that's a major slice of work taken out of the equation... Maybe it would be nice to support optlink in future, but it seems the priority is backwards. Yes, it is, but then you still won't be able to link omf and coff object files/libraries together, meaning you need a coff version of druntime/phobos/any other d libraries, and you can't use the c runtime made by dmc etc. Ideally everything would work together, and with a tool that can be bundled with D.
Re: Arbitrary abbreviations in phobos considered ridiculous
On 2012-03-08 03:14, Ary Manzana wrote:
On 3/6/12 9:25 PM, Jonathan M Davis wrote:
On Tuesday, March 06, 2012 20:58:52 Ary Manzana wrote:
On 3/6/12 8:43 PM, Jonathan M Davis wrote:
On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
writeln(time.toISOExtendedString()); // bzzt, wrong, but this
used to work!
Yes, and it was quickly changed to toISOExtString, because
toISOExtendedString is painfully long. toISOExtString is bad enough,
but
you can't really make it any shorter without making the name
uninformative.
Nope, apparently, I meant dur. Ridiculous.
A Duration needs to be constructed with a template, and
duration!hours(13), duration!seconds(44), etc. is painfully long
when
used in expressions. So, it was shortened to dur. I don't know of any
other abbreviation which would make sense.
Painfully long?
How much time does it take you to type 5 more chars? How much time does
it take you to understand dur when you read it instead of duration?
I agree with H.S. Teoh in that abbreviations should be meaniful and
consistent but that they _should_ be used where applicable. Code
becomes
painfully long otherwise - especially when chaining function calls and
the like.
Code becomes painfully long when you write lots of lines, not when you
write long lines. Specially when you write lots of boilerplate lines.
You don't write much code in functional style, do you?
Here's something I wrote today:
parent_ids = results.map{|x|
x['_source']['parent_ids']}.flatten.uniq.compact
Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
Or I could have written:
Hash[
Site.find(
results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
).map{|x| [x.id, x]}
]
No abbreviation at all, many function calls, functional style in the
middle (the couple of map).
In Ruby it's not such a big problem to have descriptive names.
I guess in D it would be longer because of all the template invocation,
the argument types, etc. I just guess it, I'm not sure.
With the new labmda syntax and the new UFCS it would be:
Site.find(
results.map!(x = x['_source']['parent_ids']).flatten.uniq.compact
).map!(x = [x.id, x]);
Don't know the corresponding D functions for flatten and compact,
you might not need them.
If you chain functions
much, then long names very quickly result in long lines, which makes
the code
harder to read, and can quickly lead to expressions having to be multiple
lines, simply because the symbol names involved were overly verbose.
While, I grant you that duration!minutes(5) might be more
immediately clear
than dur!minutes(5) is, I don't buy that it makes all that much of a
differences. You're not going to mistake dur for anything else even if it
doesn't immediately occur to you that it's an abbreviation for
duration, and
the units make it very clear that it's related to time. And since dur is
something that's likely to be commonly used, it will very quick and
easy to
remember what it is.
The problem is not mistaking it with something else. The problem is when
you want to write it. In Ruby my mind works like this:
Mind: How would I get a span for 5 seconds?
Mind: Let's try 5.seconds
Mind: Wow, it works!
I'm trying to remember cases when I just wrote what my mind thought it
was correct and I was *so* surprised it worked out of the box in Ruby.
Like writing array.last, and get it to work, instead of
array[array.length - 1]. But in D, from the docs
(http://dlang.org/arrays.html )
bar[$-1] // retrieves last element of the array
I read: bar dollar minus one wait what??
Now, in D I try:
5.seconds
and it doesn't work. I have to write this very unintuitive:
dur!minutes(5)
Was it really necessary to implement it that way?
Again, the problem is not understanding the meaning, the problem is
guessing what you have to write and get it right the first time.
I completely agree.
--
/Jacob Carlborg
Re: Poll of the week: main OS and compiler
On 8 March 2012 15:55, Daniel Murphy yebbl...@nospamgmail.com wrote: Manu turkey...@gmail.com wrote in message news:mailman.223.1331197934.4860.digitalmar...@puremagic.com... On 8 March 2012 00:21, Jonathan M Davis jmdavisp...@gmx.com wrote: Is it possible to just fix the compiler to output COFF objects *without* touching optlink at all? I'm not interested in using optlink with this feature, I intend to link with Visual Studio, that's the whole point. So ignoring optlink, that's a major slice of work taken out of the equation... Maybe it would be nice to support optlink in future, but it seems the priority is backwards. Yes, it is, but then you still won't be able to link omf and coff object files/libraries together, meaning you need a coff version of druntime/phobos/any other d libraries, and you can't use the c runtime made by dmc etc. That's fine, I would use the mscrt (required to link with all the rest of my code anyway), and as soon as the feature is available, you can bet your boots that OMF will cease to exist in windows library distributions instantly. When was the last time you saw a closed-source windows library ship with .a files? Windows library distributions would be VC compatible COFF objects within days. Ideally everything would work together, and with a tool that can be bundled with D. Optlink is bundled with D, I presume OMF would remain an option as a standalone 'complete package', but realistically, I don't think virtually any windows users would use it once they can link with VS. The kind of Windows user that might use OMF+optlink is the same kind of user that would be perfectly happy, maybe even prefer to use GDC/LDC.
Re: Poll of the week: main OS and compiler
On 2012-03-08 10:12, Manu wrote: On 8 March 2012 00:21, Jonathan M Davis jmdavisp...@gmx.com mailto:jmdavisp...@gmx.com wrote: On Wednesday, March 07, 2012 23:07:11 Mars wrote: On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote: Personally, I just want to be able to link like a normal windows developer. My code is C/C++, built with VC, and I want to link my D app against those libs using the VC linker, and debug with Visual Studio. This is the workflow I think the vast majority of Windows devs will expect, and it sounds simple enough. This is the only thing standing between me using D for any major projects, and just experimenting with the language for evaluation, or just academic interest. 64bit is far less important to me personally, VisualC linker compatibility is the big one. I just want to link against my C code without jumping through lots of hoops. That's exactly my problem... and although I love D, these hurdles made me take a step back, to C++, while I wait for this to change, so I can finally use D efficiently. I'm sure this isn't a trivial task, but the problematic isn't new after all. Why hasn't it been addressed yet? In my eyes this should be a top priority, to make it easier for new users to get into D. Till this poll I actually believed the problem was that D isn't used much by Windows users. I don' think that Walter really views it as much of a problem - or if he does, he didn't used to. Remember that he's used to an environment where he doesn't use Visual Studio or Microsoft's C++ compiler. And his customers use dmc just like he does (since they're his customers), so many of the people that he interacts with in the C/C++ world are not necessarily particularly Microsoft- centric on Windows. Add to that the enormous task that it is to actually make dmd work with COFF or 64-bit or anything of the sort on Windows, and it's no wonder that it hasn't happened yet. To be fair, there are plenty of other things that have needed to be done, and what we have for Windows does work, even if it's suboptimal. So, it's not all that unreasonable that the issue would be put off as long as it has been. And Walter _has_ been slowing working on porting optlink to C (the fact that it's written in assembly makes it really fast but hard to maintain and change), which would make it possible to then start porting stuff to 64-bit and considering COFF and stuff like that. Is it possible to just fix the compiler to output COFF objects *without* touching optlink at all? I'm not interested in using optlink with this feature, I intend to link with Visual Studio, that's the whole point. So ignoring optlink, that's a major slice of work taken out of the equation... Maybe it would be nice to support optlink in future, but it seems the priority is backwards. DMD would need to be compatible with the Microsoft linker and runtime as well, that is, except from outputting object file in the correct format. -- /Jacob Carlborg
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thursday, 8 March 2012 at 13:36:56 UTC, Jacob Carlborg wrote: auto isoExtendedString = time.toIsoExtendedString() That's my preference as well.
Re: Poll of the week: main OS and compiler
On 8 March 2012 16:41, Jacob Carlborg d...@me.com wrote: On 2012-03-08 10:12, Manu wrote: On 8 March 2012 00:21, Jonathan M Davis jmdavisp...@gmx.com mailto:jmdavisp...@gmx.com wrote: On Wednesday, March 07, 2012 23:07:11 Mars wrote: On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote: Personally, I just want to be able to link like a normal windows developer. My code is C/C++, built with VC, and I want to link my D app against those libs using the VC linker, and debug with Visual Studio. This is the workflow I think the vast majority of Windows devs will expect, and it sounds simple enough. This is the only thing standing between me using D for any major projects, and just experimenting with the language for evaluation, or just academic interest. 64bit is far less important to me personally, VisualC linker compatibility is the big one. I just want to link against my C code without jumping through lots of hoops. That's exactly my problem... and although I love D, these hurdles made me take a step back, to C++, while I wait for this to change, so I can finally use D efficiently. I'm sure this isn't a trivial task, but the problematic isn't new after all. Why hasn't it been addressed yet? In my eyes this should be a top priority, to make it easier for new users to get into D. Till this poll I actually believed the problem was that D isn't used much by Windows users. I don' think that Walter really views it as much of a problem - or if he does, he didn't used to. Remember that he's used to an environment where he doesn't use Visual Studio or Microsoft's C++ compiler. And his customers use dmc just like he does (since they're his customers), so many of the people that he interacts with in the C/C++ world are not necessarily particularly Microsoft- centric on Windows. Add to that the enormous task that it is to actually make dmd work with COFF or 64-bit or anything of the sort on Windows, and it's no wonder that it hasn't happened yet. To be fair, there are plenty of other things that have needed to be done, and what we have for Windows does work, even if it's suboptimal. So, it's not all that unreasonable that the issue would be put off as long as it has been. And Walter _has_ been slowing working on porting optlink to C (the fact that it's written in assembly makes it really fast but hard to maintain and change), which would make it possible to then start porting stuff to 64-bit and considering COFF and stuff like that. Is it possible to just fix the compiler to output COFF objects *without* touching optlink at all? I'm not interested in using optlink with this feature, I intend to link with Visual Studio, that's the whole point. So ignoring optlink, that's a major slice of work taken out of the equation... Maybe it would be nice to support optlink in future, but it seems the priority is backwards. DMD would need to be compatible with the Microsoft linker and runtime as well, that is, except from outputting object file in the correct format. By 'runtime' you mean the crt? I don't think that'll be a major headache. Probably just a few subtle differences to deal with. A nice side effect would be that all those horrid OMF conversions of MS libs bundled with D wouldn't be necessary. And what else affects linker compatibility other than object format and mangling convention? How is DMD actually affected by any of this other than object format? Name mangling?
Re: dereferencing null
On Thu, Mar 08, 2012 at 02:57:00PM +0100, Andrej Mitrovic wrote:
[...]
I don't know why we don't have __traits(allFunction). We have
'getVirtualFunctions' but it requires a function name, but using
allMembers to filter out function names is damn difficult if you ask
me.
foreach (name; __traits(allMembers, typeof(obj))) {
static if (__traits(compiles, __traits(getMember, obj,
name)))
{
alias typeof(__traits(getMember, obj, name))
type;
static if (is(type==function)) {
// name refers to a function of type
// 'type' here
}
}
}
I've never had an easy time interacting with __traits.
Me too. I'm guessing that __traits is the way it is due to ease of
implementation in the compiler. It's certainly not very friendly to use.
T
--
Маленькие детки - маленькие бедки.
Re: dereferencing null
On Mar 8, 2012, at 12:58 AM, Don Clugston d...@nospam.com wrote:
On 06/03/12 17:05, Sean Kelly wrote:
On Mar 6, 2012, at 3:14 AM, Don Clugstond...@nospam.com wrote:
Responding to traps is one of the very few examples I know of, where
Windows got it completely right,
and *nix got it absolutely completely wrong. Most notably, the hardware is
*designed* for floating point traps to be fully recoverable. It makes
perfect sense to catch them and continue.
But unfortunately the *nix operating systems are completely broken in this
regard and there's nothing we can do to fix them.
Does SEH allow recovery at the point of error like signals do?
Yes, it does. It really acts like an interrupt. You can, for example, modify
registers or memory locations, then perform the equivalent of an asm { iret;
}, so that you continue at the next instruction. Or, you can pass control to
any function, after unwinding the stack by any number of frames you chose.
And, you regain control if any other exception occurs during the unwinding,
and you're given the chance to change strategy at that point.
An SEH handler behaves a bit like setjmp(), it's not a callback.
Most importantly, in comparison to Posix, there are NO LIMITATIONS about what
you can do in an SEH exception handler. You can call any function you like.
Wow, sounds like paradise compared to signals.
The documentation is terrible, but it's really a beautiful design.
Sometimes I think it would be enough if the Posix spec were worded in a way
that allowed exceptions to be thrown from signal handlers.
I think that would be difficult to allow. Some of the restrictions seem to be
quite fundamental. (Otherwise, I'm sure they would have got rid of them by
now!)
I'm sure it's too late now. And I imagine there was a good reason for it that
I'm not aware of, just like the restrictions on kernel calls (which could have
blocked signals during execution). Performance was probably part of it. Ah
well. The last signal issue I ran into was a deadlock caused by a logger
routine calling ctime_r inside a sigchild handler. What a pain.
Re: dereferencing null - what about something like an check-scope?
could it be a good idea to add something like an check-scope for
modules,functions,etc. for typical fails to easy the detection?
wild-idea-and-syntax-list:
@CheckForNull
@CheckForNaN
@CheckForUnnormalFloat
...
x.d
modul x
@CheckForNull // will introduce NullChecks for the complete module
..
..
..
-
int test()
{
@CheckForNull; // introduces Null-Checks on the function scope
@CheckForNaN; // introduces NaN-Checks on the function scope
...very long evil function...
}
total waste of compiler-developer time - or something to make D better
in the end?
Random access range
import std.stdio;
struct Rar{
int[] data = [1,3,5];
int length = 3;
ref int opIndex(int i){ return data[i];}
}
void main() {
Rar x;
foreach (e; x)
writeln(e);
}
Error: invalid foreach aggregate x
Is'nt Rar valid random access range?
Re: dereferencing null
On 3/8/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
foreach (name; __traits(allMembers, typeof(obj))) {
static if (__traits(compiles, __traits(getMember, obj,
name)))
{
alias typeof(__traits(getMember, obj, name))
type;
static if (is(type==function)) {
// name refers to a function of type
// 'type' here
}
}
}
I've never had an easy time interacting with __traits.
Yesterday I've tried the same thing but it didn't work because I was
missing the __traits call. With that in place, here's a very
hardcoded example of what you can do in D:
http://paste.pocoo.org/show/562933/
So now you can catch the exception if the object was uninitialized.
And you didn't have to modify the target class at all.
Re: dereferencing null
Sorry, mixin(getOverloads!(UnreliableResource)()); should be: mixin(getOverloads!(Base)());
Re: dereferencing null
Plus I left over some code. Anyway the point is that was just a hardcoded example of something that's doable, you'd probably want it to be much more sophisticated before it goes into a library.
Re: Random access range
On Thu, 08 Mar 2012 11:43:24 -0500, zeljkog zelj...@home.com wrote:
import std.stdio;
struct Rar{
int[] data = [1,3,5];
int length = 3;
ref int opIndex(int i){ return data[i];}
}
void main() {
Rar x;
foreach (e; x)
writeln(e);
}
Error: invalid foreach aggregate x
Is'nt Rar valid random access range?
No, a random access range must also be a bidirectional and input range.
You need the standard range primitives.
-Steve
Re: Random access range
On Thursday, 8 March 2012 at 16:43:25 UTC, zeljkog wrote:
import std.stdio;
struct Rar{
int[] data = [1,3,5];
int length = 3;
ref int opIndex(int i){ return data[i];}
}
void main() {
Rar x;
foreach (e; x)
writeln(e);
}
Error: invalid foreach aggregate x
Is'nt Rar valid random access range?
struct N(T){
T[] arr;
this(T[] other){ arr = other; }
this(N other){ arr = other.arr; }
// The declarations below are required
// The @property tag is also required
ref T opIndex(size_t i){ return arr[i]; }
@property size_t length(){ return arr.length; }
@property ref T front(){ return arr.front; }
@property ref T back(){ return arr.back; }
void popFront(){ arr.popFront(); }
void popBack(){ arr.popBack(); }
@property bool empty(){ return arr.empty; }
@property N save(){ return N(arr); }
}
Re: dereferencing null - what about something like an check-scope?
I like the way Scala handles this with the Option class. None indicates no value which is equivalent to your null sentinal value but it is a value itself so it is always safe to use. Combined with pattern matching and the orElse methods makes it very easy to use one variable that both stores the value and at the same time indicates whether it is valid or not. It's not two variables that could get out of sync.
Re: dereferencing null
On Thu, Mar 08, 2012 at 05:49:20PM +0100, Andrej Mitrovic wrote:
On 3/8/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
foreach (name; __traits(allMembers, typeof(obj))) {
static if (__traits(compiles, __traits(getMember, obj,
name)))
{
alias typeof(__traits(getMember, obj, name))
type;
static if (is(type==function)) {
// name refers to a function of type
// 'type' here
}
}
}
I've never had an easy time interacting with __traits.
Yesterday I've tried the same thing but it didn't work because I was
missing the __traits call. With that in place, here's a very
hardcoded example of what you can do in D:
http://paste.pocoo.org/show/562933/
So now you can catch the exception if the object was uninitialized.
And you didn't have to modify the target class at all.
Cool! That's a really neat way of doing it. Love the combination of
alias this, compile-time introspection, and the awesomeness of D
templates. D r0x0rs!
T
--
Your inconsistency is the only consistent thing about you! -- KD
Re: inout and function/delegate parameters
On 03/08/2012 12:37 PM, Steven Schveighoffer wrote: On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr timon.g...@gmx.ch wrote: On 03/07/2012 11:37 PM, Stewart Gordon wrote: On 07/03/2012 15:41, Steven Schveighoffer wrote: snip In fact, I think this is valid D code: int i; const int *pi = i; int *p = cast()pi; *p = 5; // legal because I know this points at i, and i is really mutable cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works. It is not legal code. I did not point it out because it was clear what was meant. cast() only casts away the top level of modifiers. It is perfectly safe except for class objects. If it's not legal code, then how is implicitly casting away inout during function execution legal code? Isn't this the same thing? -Steve It is not legal code because the assignment const(int)* to int* does not succeed. The other part is up to debate. The specification does not define the semantics of casting away const and changing the data. It is also not the same as with the proposed change to inout. inout would not be 'removed' in the function body, it would be 'removed' upon inout-matching the parameters. Inout should be able to replace overloads on const, therefore I think that is the way it should work on the conceptual level.
Re: Arbitrary abbreviations in phobos considered ridiculous
On 03/08/2012 12:55 PM, Steven Schveighoffer wrote:
On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana a...@esperanto.org.ar
wrote:
The problem is not mistaking it with something else. The problem is
when you want to write it. In Ruby my mind works like this:
Mind: How would I get a span for 5 seconds?
Mind: Let's try 5.seconds
Mind: Wow, it works!
I'm trying to remember cases when I just wrote what my mind thought it
was correct and I was *so* surprised it worked out of the box in Ruby.
Like writing array.last, and get it to work, instead of
array[array.length - 1]. But in D, from the docs
(http://dlang.org/arrays.html )
bar[$-1] // retrieves last element of the array
I read: bar dollar minus one wait what??
array.back;
http://dlang.org/phobos/std_array.html#back
This is the issue with intuition. It's easy to say, hey I guessed
right in Ruby! Ruby must be more intuitive!. But if you were someone
who knew the range interfaces, wouldn't you try array.back in Ruby and
say well, obviously D is more intuitive, it knew what I wanted without
even looking up the docs!
You are never going to come up with something that's *perfectly*
intuitive for everyone in every situation.
Now, in D I try:
5.seconds
and it doesn't work. I have to write this very unintuitive:
dur!minutes(5)
Was it really necessary to implement it that way?
No, nothing is ever necessary to implement a certain way. But there are
practical concerns. For example, assuming UFCS worked in D, you *could*
possibly do 5.seconds. However, this means you need a module-level
function:
Duration seconds(long n) {...}
But the way D's overload resolution works, this precludes having
5.seconds work, and also having a member named 'seconds' in your
class/struct.
Actually, UFCS functions are currently always looked up at the module level.
Thread on GO at hacker news
Submission is titled The Go Programming Language, or: Why all C-like languages except one suck. But not argument is made for D. http://news.ycombinator.com/item?id=3680732
Re: Thread on GO at hacker news
Seems like this was discussed before, as well as D: http://news.ycombinator.com/item?id=2631964
Re: [OT] American versus British spelling and pronunciation (was:Arbitrary abbreviations in phobos considered ridiculous)
James Miller ja...@aatch.net wrote in message news:mailman.235.1331210469.4860.digitalmar...@puremagic.com... On 9 March 2012 01:23, Stewart Gordon smjg_1...@yahoo.com wrote: I'm finding it hard to figure how someone would pronounce the o and u in colour separately. I would imagine it'd be like kuh-lore. Being British means that I do notice the differences in pronunciation, I've pretty much done the opposite to Reagan, gone from England to NZ. I tend to get frustrated when I can't even correct pronunciation because nobody can hear the difference! I have a little extra insight into this as my mom is a speech/language pathologist: As you've noticed, trying to get a person to hear the difference often doesn't work (And even if they can hear it, that doesn't necessarily give them enough info to actually pronounce it). I think the right thing to do, at least in cases where it actually matters, is to instruct them on the actual mouth movements involved. Then they can feel the difference, and start to hear themselves making the different sound. Hearing it can naturally follow from that. When I started (trying to) learn Japanese, I had trouble hearing the Japanese R sound. But the instructor explained how to pronounce it: Pay attention to how your tongue is positioned when saying the English R and L. For the Japanese R, do the same thing, but put your tongue about half-way in-between: just in front of what's called the boney ridge instead of just behind it (English R) or on the back of the teeth (English L). After learning that, I was able to not only pronounce it (more or less) but also hear the difference much better since I actually knew what to expect (interestingly, the Japanese R frequently sounds more like a D than an English L or R). A similar thing is the tsu sound in Japanese. The TS combination is very intimidating for most English speakers, and I doubt many English speakers can easily hear it. But as my class's instructor pointed out: It's exactly like the ts at the end of boots. So just say that and folow up with a u. Now I can say and hear it just fine (At least, I *think* I can - a native Japanese speaker would have to be the real judge).
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thursday, March 08, 2012 06:55:17 Steven Schveighoffer wrote: On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana a...@esperanto.org.ar wrote: The problem is not mistaking it with something else. The problem is when you want to write it. In Ruby my mind works like this: Mind: How would I get a span for 5 seconds? Mind: Let's try 5.seconds Mind: Wow, it works! I'm trying to remember cases when I just wrote what my mind thought it was correct and I was *so* surprised it worked out of the box in Ruby. Like writing array.last, and get it to work, instead of array[array.length - 1]. But in D, from the docs (http://dlang.org/arrays.html ) bar[$-1] // retrieves last element of the array I read: bar dollar minus one wait what?? array.back; http://dlang.org/phobos/std_array.html#back This is the issue with intuition. It's easy to say, hey I guessed right in Ruby! Ruby must be more intuitive!. But if you were someone who knew the range interfaces, wouldn't you try array.back in Ruby and say well, obviously D is more intuitive, it knew what I wanted without even looking up the docs! You are never going to come up with something that's *perfectly* intuitive for everyone in every situation. Yeah. I don't understand how anyone can expect to just write code and have it work without looking anything up. Best case, the IDE does code completion for you, and maybe you don't have to actually look at the docs, but without knowing what the functions do, that's not necessarily wise even if the functions are well-named, because they still might not do _exactly_ what you expect (and everyone's expectations vary). The names need to be good enough that the code is reasonably understandable without necessarily having to look at the documentation (though there's a good chance that you're still going to have to look at the docs), and they should be good enough that most people have a good chance of finding what they're looking for when they look for a funcition or type in the docs. But there are so many variations on how things can be named, and so many people expect different things, that you're never going to win. At best, you please the majority. But names are _always_ bikeshedding issues. A _lot_ of what goes into symbol naming is personal preference and a matter of what you've previously been exposed to rather than anything objective, and there will pretty much always be disagreements on it. - Jonathan M davis
Re: How to design date/time libraries (was: Arbitrary abbreviations in phobos considered ridiculous)
On Thursday, March 08, 2012 12:09:29 Stewart Gordon wrote: On 08/03/2012 02:56, Jonathan M Davis wrote: On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote: On 07/03/2012 08:10, Jacob Carlborg wrote: snip Yeah, Clock.now() would be good and Data.today() as well. My utility library has, for consistency, DateValue.now, TimeValue.now and DateTime.now. I specically avoided giving a way to get the time with any type other than SysTime (and TickDuration for using a monotonic clock), because I believe that it leads to incorrect behavior. Any time that you're dealing with the system clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are for when you need the date and/or time but don't care about what absolute time it's associated with in the real world. Treating DateTime as corresponding to a specific point in time is just going to cause problems, because it has no time zone. snip TimeValue and DateTime in my library always store the time in UTC. It uses a global variable for time zone. But a LocalTime could be added to the mix. This would be used to hold a time that, when combined with a date, will become a DateTime set according to the correct time zone. Which is very different from Date, TimeOfDay, and DateTime in std.datetime, since those are effectively calendar dates/times with no concept of time zone. They're just the date and/or time (e.g. 2012-02-05 or 14:07), which can be _very_ useful, but it means that you have to realize that you should be using SysTime when you actually want the system time and/or an absolute time rather than a generic date and/or time that you're not really going to try and associate to a particular system time. Actually, when I was doing some date/time stuff at work (in C++), I tried to port a version of SysTime over _without_ Date, TimeOfDay, and DateTime, since all we cared about for our stuff was the system time, and I ended up having to add them anyway, because they simplified things so much (if nothing else, SysTime needs them to do a lot of its stuff). Interestingly, SQL has DATE - just a date, simple as that TIME - a time of day in unspecified time zone TIMETZ - a time of day with time zone specified TIMESTAMP - a date/time combination in unspecified time zone TIMESTAMPTZ - an absolute instant in time, which can be constructed and examined according to the system time zone Notice how different TIMETZ and TIMESTAMPTZ are, even though TZ abbreviates WITH TIME ZONE in both cases. Moreover, system time zones (in at least some SQL implementations) include DST rules, whereas the zone stored in a TIMETZ is just a UTC offset. In my scheme: - DateValue corresponds to DATE - TimeValue corresponds to a TIMETZ with the zone set as UTC - DateTime corresponds to TIMESTAMPTZ - LocalTime, if it were added, would correspond to TIME I'd also like to add DST handling to my library, but it'll take thinking about. I'm not sure what OS APIs have in the way of retrieving the DST rules for the locale. Though I have just discovered GetDynamicTimeZoneInformation in the Windows API - I'll investigate it later. LOL. The OS APIs suck at giving proper time info, and Windows' not only has very few time zones, but their data is _frequently_ wrong - especially with regards to DST. You're also stuck reading the registry if you want timezone- specific information rather than simply info for the current time zone. GetDynamicTimeZoneInformation is an attempt to fix their very broken, historical API (GetTimeZoneInformation) which doesn't take into account the fact that DST rules can change. GetDynamicTimeZoneInformation does, but it only exists on Vista+. However, Microsoft made it so that the functions that use the result from GetTimeZoneInformation basically ignore what's in that struct and use the same information that the struct from GetDynamicTimeZoneInformation uses (probably by either using a memcmp or checking the time zone's name to determine that it's a known timezone). And _all_ of that is highly broken in that it bases DST switches off of the _local_ time rather than UTC. It was a nightmare to sort all of that out. In general, Posix does much better (though you do end up having to read the timezone files yourself if you want to use anything other than the local timezone). It's information is _much_ more accurate, and it bases everything off of UTC. However, unlike Windows, it's a royal pain to figure out what the local timezone is. And the C API that they give you sucks just as much as the Windows one does. Yeah. I could probably complain for hours about how pathetic the time stuff is that the OSes provide. So, I'll shut up now. I think that std.datetime does a good job of building on top of what's there, but the patheticness of the C APIs made it a lot harder than it should be. - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thursday, 8 March 2012 at 19:04:32 UTC, Jonathan M Davis wrote: Yeah. I don't understand how anyone can expect to just write code and have it work without looking anything up. What prompted me to start this thread is that I knew it was core.time.duration!hours already except it was actually dur. I had looked it up previously, but filed it in my brain under duration rather than the nonsense dur.
Re: Poll of the week: main OS and compiler
On Thursday, March 08, 2012 17:12:53 Manu wrote: On 8 March 2012 16:41, Jacob Carlborg d...@me.com wrote: DMD would need to be compatible with the Microsoft linker and runtime as well, that is, except from outputting object file in the correct format. By 'runtime' you mean the crt? I don't think that'll be a major headache. Probably just a few subtle differences to deal with. A nice side effect would be that all those horrid OMF conversions of MS libs bundled with D wouldn't be necessary. And what else affects linker compatibility other than object format and mangling convention? How is DMD actually affected by any of this other than object format? Name mangling? As I understand it, Walter used to have it so that dmc (not dmd) could generate code compatible with Microsoft's format, but it was such a pain to maintain it with the changes that Microsoft kept making that he gave up on it. So, I'm not at all certain that anything involved with making dmd compatible with COFF is easy or easy to maintain. That doesn't mean that it shouldn't be done (far from it), but I wouldn't assume that much of anything involved with it isn't a big issue (like just a few subtle differences to deal with). We _might_ be that lucky, but I wouldn't bet on it. It's a major undertaking - albeit an important one. - Jonathan M Davis
Re: Poll of the week: main OS and compiler
On Thursday, March 08, 2012 11:20:03 Bernard Helyer wrote: On Thursday, 8 March 2012 at 09:25:19 UTC, Jonathan M Davis wrote: On Thursday, March 08, 2012 09:45:34 David Nadlinger wrote: On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote: Walter, how big is it really? Small enough to be done as, say, a gsoc project? Would you be interested in mentoring such a project? I don't know whether it would really be a problem from a legal (Google) point of view, but having a GSoC student work on non-Open Source software seems strange at least. I though that GSoC had a list of licenses which were acceptable for GSoC projects - all of which are open source license of one variety or another. - Jonathan M Davis That's his point; the backend isn't open source. ?? David doesn't seem to making that point. He's saying that it would be strange, not that it would be against the rules. - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
Alix Pexton alix.dot.pex...@gmail.dot.com wrote in message news:jja8k8$j14$1...@digitalmars.com... I feel compelled to point out that there is no such thing as British English. There is English, the written language with all its archaic spellings and there are many spoken dialects, the most formal of which is RP (Received Pronunciation) sometimes called The Queen's English (even though she is German). Yea, that is a good point. OTOH, it's often convenient (and common) to assume one particular de facto standard dialict unless otherwise stated. Here in the US, we have regional dialects too (although perhaps not to the same extent as how much the British dialects differ from each other), but when people either inside or outside the US refer to American English, typically they're referring to the one that's spoken in the US mid-west and on TV/movies. Similarly, in the western world, Japanese is, by default, considered to be the Tokyo dialect (as opposed to Kansai or whatever other ones there may be). It might be different in Europe, but in the US, we think of British English, unless otherwise specified, as being the London/Queen's English version. At least, those of us who are aware of the varied British dialects ;) FWIW. I tolerate USian spellings I see I'm not the only one with a pet peeve that 'America' is two continents, not one country :) as much as non-English speaking programmers do, because I see it as an accepted Programmer's English. Being from the US I couldn't be sure, but that's what I has suspected.
dlang.org Articles without Authors
I would like the authors of all the pages accessible by the Articles link to be given credit for their writings. It's inconsistent because some have their author listed and others don't. These are a few which have no author listed: http://dlang.org/exception-safe.html http://dlang.org/hijack.html http://dlang.org/regular-expression.html http://dlang.org/tuple.html Thank you, Zach
Re: Arbitrary abbreviations in phobos considered ridiculous
Timon Gehr timon.g...@gmx.ch wrote in message news:jjat9r$1pvp$2...@digitalmars.com... Actually, UFCS functions are currently always looked up at the module level. Which is annoying: http://d.puremagic.com/issues/show_bug.cgi?id=7291
Re: [OT] American versus British spelling and pronunciation (was:Arbitrary abbreviations in phobos considered ridiculous)
On Thu, Mar 08, 2012 at 01:55:45PM -0500, Nick Sabalausky wrote: James Miller ja...@aatch.net wrote in message news:mailman.235.1331210469.4860.digitalmar...@puremagic.com... [...] Being British means that I do notice the differences in pronunciation, I've pretty much done the opposite to Reagan, gone from England to NZ. I tend to get frustrated when I can't even correct pronunciation because nobody can hear the difference! I have a little extra insight into this as my mom is a speech/language pathologist: As you've noticed, trying to get a person to hear the difference often doesn't work (And even if they can hear it, that doesn't necessarily give them enough info to actually pronounce it). I think the right thing to do, at least in cases where it actually matters, is to instruct them on the actual mouth movements involved. Then they can feel the difference, and start to hear themselves making the different sound. Hearing it can naturally follow from that. I couldn't agree more! When I first started learning Russian, I simply could not hear the difference between И and Ы. At all. They sounded identical to me. Or rather, I notice there's a difference when a native speaker says both sounds, but I couldn't pinpoint what that difference was, nor could I reproduce the sounds, or distinguish between them when heard in isolation. It took a lot of research to find out exactly how to pronounce Ы (И is relatively easy), and a lot of effort to learn how to tell them apart in different contexts, before I started hearing the difference. Now I was somewhat lucky that my mother tongue distinguishes between an aspirated T (the T at the beginning of an English word) and a non-aspirated T (the Russian Т, or, for that matter, the Spanish T). So I had no trouble pronouncing the Russian T correctly, but another guy who was also learning Russian couldn't tell the difference, and as a result always spoke with a heavy foreigner accent. I can't say I've mastered it all, though... one thing that still throws me off is Л and ЛЬ right before a consonant. I can do it right if a vowel immediately follows, but I have a lot of trouble if ЛЬ is followed by a consonant. I couldn't hear the difference at all. Now I can somewhat tell, but I still slip up all the time when I try to pronounce it myself. Another thing is, I can't roll my R's. My tongue as stiff as a stick and just refuses to roll anything, no matter how hard I try. I've tried to follow online tutorials, but it just doesn't work for me. :-( T -- Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye
Re: Thread on GO at hacker news
Robert McGinley mcginle...@gmail.com wrote in message news:mtjrxlbyeunoueqds...@forum.dlang.org... Submission is titled The Go Programming Language, or: Why all C-like languages except one suck. But not argument is made for D. http://news.ycombinator.com/item?id=3680732 [Issue 9] is a C-like language...It is intended to be a systems programming language... Bleh. Google's Issue 9 is neither a C-like language nor a systems language.
Re: inout and function/delegate parameters
On Thu, 08 Mar 2012 13:17:15 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/08/2012 12:37 PM, Steven Schveighoffer wrote:
On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 03/07/2012 11:37 PM, Stewart Gordon wrote:
On 07/03/2012 15:41, Steven Schveighoffer wrote:
snip
In fact, I think this is valid D code:
int i;
const int *pi = i;
int *p = cast()pi;
*p = 5; // legal because I know this points at i, and i is really
mutable
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that
it
works.
It is not legal code. I did not point it out because it was clear what
was meant. cast() only casts away the top level of modifiers. It is
perfectly safe except for class objects.
If it's not legal code, then how is implicitly casting away inout during
function execution legal code? Isn't this the same thing?
-Steve
It is not legal code because the assignment const(int)* to int* does not
succeed.
Oh right, I forgot that casting using cast() just goes to the tail-const
version. grr... We really need const_cast...
The other part is up to debate. The specification does not define the
semantics of casting away const and changing the data.
Yes, I couldn't really find that. It does specifically say casting away
const and then modifying is invalid, but it does not say anything about
if you know the underlying data is mutable. But again, this is the
point I was trying to make, we are casting away a const-like attribute and
modifying the data.
It is also not the same as with the proposed change to inout. inout
would not be 'removed' in the function body, it would be 'removed' upon
inout-matching the parameters. Inout should be able to replace overloads
on const, therefore I think that is the way it should work on the
conceptual level.
It is essentially the same as this:
void bar(const(int) * i, void delegate(const(int)* i) dg) {dg(i);}
void main()
{
void foo(int *i) {*i = 5;}
bar(i, cast(delegate(const(int)*)) foo);
}
Which I don't know if it's valid. Given that compiler enforcement of
inout being *sure* that the data is actually mutable, it's much safer than
what I wrote above, but it's certainly no different. It's just
compiler-checked vs. manually checked.
-Steve
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thu, Mar 08, 2012 at 02:04:20PM -0500, Jonathan M Davis wrote: [...] The names need to be good enough that the code is reasonably understandable without necessarily having to look at the documentation (though there's a good chance that you're still going to have to look at the docs), and they should be good enough that most people have a good chance of finding what they're looking for when they look for a funcition or type in the docs. But there are so many variations on how things can be named, and so many people expect different things, that you're never going to win. At best, you please the majority. But names are _always_ bikeshedding issues. +1. A _lot_ of what goes into symbol naming is personal preference and a matter of what you've previously been exposed to rather than anything objective, and there will pretty much always be disagreements on it. [...] That's true. Most of the abbreviations I've been comfortable with are those that I've learned when I was a teenage aspiring programmer. In retrospect, a lot of it makes no sense. I just preferred it that way 'cos that's the way I first learned it, and AFAICT at the time, that was the way it had *always* been (which is, of course, not true in retrospect). T -- Любишь кататься - люби и саночки возить.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thu, 08 Mar 2012 14:07:13 -0500, Adam D. Ruppe destructiona...@gmail.com wrote: On Thursday, 8 March 2012 at 19:04:32 UTC, Jonathan M Davis wrote: Yeah. I don't understand how anyone can expect to just write code and have it work without looking anything up. What prompted me to start this thread is that I knew it was core.time.duration!hours already except it was actually dur. I had looked it up previously, but filed it in my brain under duration rather than the nonsense dur. Thanks to this thread, I bet you never forget that again ;) I know I won't... -Steve
Re: Poll of the week: main OS and compiler
On 2012-03-08 16:12, Manu wrote: On 8 March 2012 16:41, Jacob Carlborg d...@me.com mailto:d...@me.com wrote: On 2012-03-08 10:12, Manu wrote: On 8 March 2012 00:21, Jonathan M Davis jmdavisp...@gmx.com mailto:jmdavisp...@gmx.com mailto:jmdavisp...@gmx.com mailto:jmdavisp...@gmx.com wrote: On Wednesday, March 07, 2012 23:07:11 Mars wrote: On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote: Personally, I just want to be able to link like a normal windows developer. My code is C/C++, built with VC, and I want to link my D app against those libs using the VC linker, and debug with Visual Studio. This is the workflow I think the vast majority of Windows devs will expect, and it sounds simple enough. This is the only thing standing between me using D for any major projects, and just experimenting with the language for evaluation, or just academic interest. 64bit is far less important to me personally, VisualC linker compatibility is the big one. I just want to link against my C code without jumping through lots of hoops. That's exactly my problem... and although I love D, these hurdles made me take a step back, to C++, while I wait for this to change, so I can finally use D efficiently. I'm sure this isn't a trivial task, but the problematic isn't new after all. Why hasn't it been addressed yet? In my eyes this should be a top priority, to make it easier for new users to get into D. Till this poll I actually believed the problem was that D isn't used much by Windows users. I don' think that Walter really views it as much of a problem - or if he does, he didn't used to. Remember that he's used to an environment where he doesn't use Visual Studio or Microsoft's C++ compiler. And his customers use dmc just like he does (since they're his customers), so many of the people that he interacts with in the C/C++ world are not necessarily particularly Microsoft- centric on Windows. Add to that the enormous task that it is to actually make dmd work with COFF or 64-bit or anything of the sort on Windows, and it's no wonder that it hasn't happened yet. To be fair, there are plenty of other things that have needed to be done, and what we have for Windows does work, even if it's suboptimal. So, it's not all that unreasonable that the issue would be put off as long as it has been. And Walter _has_ been slowing working on porting optlink to C (the fact that it's written in assembly makes it really fast but hard to maintain and change), which would make it possible to then start porting stuff to 64-bit and considering COFF and stuff like that. Is it possible to just fix the compiler to output COFF objects *without* touching optlink at all? I'm not interested in using optlink with this feature, I intend to link with Visual Studio, that's the whole point. So ignoring optlink, that's a major slice of work taken out of the equation... Maybe it would be nice to support optlink in future, but it seems the priority is backwards. DMD would need to be compatible with the Microsoft linker and runtime as well, that is, except from outputting object file in the correct format. By 'runtime' you mean the crt? I don't think that'll be a major headache. Probably just a few subtle differences to deal with. A nice side effect would be that all those horrid OMF conversions of MS libs bundled with D wouldn't be necessary. Yes, the runtime used by the Microsoft compiler. And what else affects linker compatibility other than object format and mangling convention? How is DMD actually affected by any of this other than object format? Name mangling? Jonathan explained this very good. -- /Jacob Carlborg
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thursday, 8 March 2012 at 19:48:19 UTC, Steven Schveighoffer wrote: Thanks to this thread, I bet you never forget that again ;) I know I won't... Indeed. I actually did get currTime() right this time around, thanks to etching it in after getting it wrong the last two times. Eventually, we get used to whatever name and can remember it. (Unless it is PHP's library which I swear self-mutates any time you aren't looking at it.) Still though, we've spent a lot of time in phobos on things like capitalization so we can remember it without special thought. I really want to do the same on the abbreviations too.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thu, Mar 08, 2012 at 08:53:44PM +0100, Adam D. Ruppe wrote: On Thursday, 8 March 2012 at 19:48:19 UTC, Steven Schveighoffer wrote: Thanks to this thread, I bet you never forget that again ;) I know I won't... Indeed. I actually did get currTime() right this time around, thanks to etching it in after getting it wrong the last two times. Eventually, we get used to whatever name and can remember it. (Unless it is PHP's library which I swear self-mutates any time you aren't looking at it.) [...] Heh, I didn't know PHP had quantum mechanical properties. ;-) Can you imagine PHP being the first language to run on a quantum computer? Oh the horrors! Still though, we've spent a lot of time in phobos on things like capitalization so we can remember it without special thought. I really want to do the same on the abbreviations too. IMO, making all abbreviations in Phobos consistent would be a big step forward. But Walter didn't seem to pleased about the recent pull request to add aliases for seconds/secs, so this may or may not actually happen. :-( T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Multiple return values...
I find myself really wishing for proper multiple return values almost every day, particularly when I work with maths heavy code, and especially for efficiently returning error codes in functions I'd rather not throw from. Many maths-y functions return some sort of pair; intersections return (ray, t) or something of that type. I'm finding HEAPS of SIMD functions want to return pairs (unpacks in particular): int4 (low, hight) = unpack(someShort8); Currently I have to duplicate everyting: int4 low = unpackLow(someShort8); int4 high = unpackHigh(someShort8); I'm getting really sick of that, it feels so... last millennium. The point of 'proper' multiple return values is to return each value in registers, in its own register type, using exactly the same register assignment pattern as when passing args TO functions. I don't think this causes any side effects to the ABI, since the arg registers are already volatile across function calls in the first place. It just means that the returned-to function can find its return values already conveniently in an appropriate register, avoiding memory access. People argue I should return a tuple, but this isn't really the same, it has hidden implications that complicate the optimisation potential. For instance, tuples have an implicit structure/memory layout which can't be ignored, whereas return values don't have memory allocated, ie, you can't take the address of a return value without first assigning it to some local syntactically. The implementation of efficient tuple return values would be much more complicated I would imagine too, and the rules are less clear; I can't intuitively presume what behaviour returning a tuple of different things should actually have in terms of register assignment. I also know precisely how multiple return values should work, because it is exactly the same as passing arguments to the function, but in reverse. ... just saying :)
Re: Arbitrary abbreviations in phobos considered ridiculous
On Fri, 09 Mar 2012 06:42:15 +1100, H. S. Teoh hst...@quickfur.ath.cx wrote: Most of the abbreviations I've been comfortable with are those that I've learned when I was a teenage aspiring programmer. You've just reminded me about an incident that happened to me. In a previous age, I was a Computer Operator (IBM System 360/25 - a mainframe) and was teaching myself COBOL during the night shifts. I wrote a little program to solve quadratic equations and called it QUADCALC. One day my boss called me into his office because he noticed it was run only a night time and wanted to know what it was. I explained and everything turned out ok for me (I was promoted in fact to a trainee programmer). But he initially thought I'd written a program to calculate horse racing Quadrella predictions, which would have been very inappropriate use of company time. Gotta love those abbreviations. -- Derek Parnell Melbourne, Australia
Re: Multiple return values...
On Thu, Mar 08, 2012 at 10:08:41PM +0200, Manu wrote: I find myself really wishing for proper multiple return values almost every day, particularly when I work with maths heavy code, and especially for efficiently returning error codes in functions I'd rather not throw from. Many maths-y functions return some sort of pair; intersections return (ray, t) or something of that type. I'm finding HEAPS of SIMD functions want to return pairs (unpacks in particular): int4 (low, hight) = unpack(someShort8); Currently I have to duplicate everyting: int4 low = unpackLow(someShort8); int4 high = unpackHigh(someShort8); I'm getting really sick of that, it feels so... last millennium. The point of 'proper' multiple return values is to return each value in registers, in its own register type, using exactly the same register assignment pattern as when passing args TO functions. I don't think this causes any side effects to the ABI, since the arg registers are already volatile across function calls in the first place. It just means that the returned-to function can find its return values already conveniently in an appropriate register, avoiding memory access. People argue I should return a tuple, but this isn't really the same, it has hidden implications that complicate the optimisation potential. For instance, tuples have an implicit structure/memory layout which can't be ignored, whereas return values don't have memory allocated, ie, you can't take the address of a return value without first assigning it to some local syntactically. [...] Couldn't you just use ref parameters? Or does the compiler turn them into pointers? T -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst
Re: Arbitrary abbreviations in phobos considered ridiculous
On 3/8/12 7:27 AM, Timon Gehr wrote:
On 03/08/2012 03:14 AM, Ary Manzana wrote:
Here's something I wrote today:
parent_ids = results.map{|x|
x['_source']['parent_ids']}.flatten.uniq.compact
Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
Or I could have written:
Hash[
Site.find(
results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
).map{|x| [x.id, x]}
]
No abbreviation at all,
uniq.
Oh, right, I didn
Signal and Slots
Today I tried std.signals for the first time. I've been using Qt for the past 4 years, and a noticeable difference to me is how simple it is to set up signals and slots with std.signals. But there are two things that I wish were different: 1. thread safe signals and slots. I really like this feature in Qt, and I'm wondering if this is something that will be addressed in future releases of Phobos? 2. unable to connect a signal to another signal. And this? Also, how stable is std.signals? Is it set in stone, or is it going to change ?
Re: Arbitrary abbreviations in phobos considered ridiculous
On 3/8/12 8:55 AM, Steven Schveighoffer wrote: On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana a...@esperanto.org.ar wrote: The problem is not mistaking it with something else. The problem is when you want to write it. In Ruby my mind works like this: Mind: How would I get a span for 5 seconds? Mind: Let's try 5.seconds Mind: Wow, it works! I'm trying to remember cases when I just wrote what my mind thought it was correct and I was *so* surprised it worked out of the box in Ruby. Like writing array.last, and get it to work, instead of array[array.length - 1]. But in D, from the docs (http://dlang.org/arrays.html ) bar[$-1] // retrieves last element of the array I read: bar dollar minus one wait what?? array.back; http://dlang.org/phobos/std_array.html#back This is the issue with intuition. It's easy to say, hey I guessed right in Ruby! Ruby must be more intuitive!. But if you were someone who knew the range interfaces, wouldn't you try array.back in Ruby and say well, obviously D is more intuitive, it knew what I wanted without even looking up the docs! You are never going to come up with something that's *perfectly* intuitive for everyone in every situation. Thanks, I didn't know that function. The problem is, you don't go saying Hey, I want the back of an array, (or the back element of an array) you usually say I want the last element of an array (or range, whatever). I can't understand why back was used instead of last.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Thu, Mar 08, 2012 at 05:45:47PM -0300, Ary Manzana wrote:
On 3/8/12 7:27 AM, Timon Gehr wrote:
On 03/08/2012 03:14 AM, Ary Manzana wrote:
Here's something I wrote today:
parent_ids = results.map{|x|
x['_source']['parent_ids']}.flatten.uniq.compact
Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
Or I could have written:
Hash[
Site.find(
results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
).map{|x| [x.id, x]}
]
No abbreviation at all,
uniq.
[...]
And ids.
T
--
In a world without fences, who needs Windows and Gates? -- Christian Surchi
Re: Arbitrary abbreviations in phobos considered ridiculous
On 03/08/2012 02:13 PM, Nick Sabalausky wrote: Alix Pextonalix.dot.pex...@gmail.dot.com wrote in message news:jja8k8$j14$1...@digitalmars.com... I feel compelled to point out that there is no such thing as British English. There is English, the written language with all its archaic spellings and there are many spoken dialects, the most formal of which is RP (Received Pronunciation) sometimes called The Queen's English (even though she is German). Yea, that is a good point. OTOH, it's often convenient (and common) to assume one particular de facto standard dialict unless otherwise stated. Here in the US, we have regional dialects too (although perhaps not to the same extent as how much the British dialects differ from each other), but when people either inside or outside the US refer to American English, typically they're referring to the one that's spoken in the US mid-west and on TV/movies. Similarly, in the western world, Japanese is, by default, considered to be the Tokyo dialect (as opposed to Kansai or whatever other ones there may be). It might be different in Europe, but in the US, we think of British English, unless otherwise specified, as being the London/Queen's English version. At least, those of us who are aware of the varied British dialects ;) FWIW. I recall my theater director telling me that the closest modern dialect to Shakespearean English was somewhere near the south side of the state of New York...not sure how much truth there is to that, but it's a cool idea. Regional dialects are definitely a thing in the US, but I agree that they're not always noticeable...unless you find just the right words for someone to say that accent their pronunciation, like the classic pahk the cah in hahvahd yahd that goes with a Bostonian accent. I tolerate USian spellings I see I'm not the only one with a pet peeve that 'America' is two continents, not one country :) American does have the benefit of being more pronounceable, though...I just tried to pronounce that oohz-ee-an, us-ee-an, etc and they all sound odd. as much as non-English speaking programmers do, because I see it as an accepted Programmer's English. Being from the US I couldn't be sure, but that's what I has suspected. To be honest, I've occasionally wondered why there aren't any (commonly used) programming languages using other human languages as bases. I mean, English doesn't exactly have the nicest syntax ever...USian here, though.
Re: Multiple return values...
On 8 March 2012 22:13, H. S. Teoh hst...@quickfur.ath.cx wrote: On Thu, Mar 08, 2012 at 10:08:41PM +0200, Manu wrote: I find myself really wishing for proper multiple return values almost every day, particularly when I work with maths heavy code, and especially for efficiently returning error codes in functions I'd rather not throw from. Many maths-y functions return some sort of pair; intersections return (ray, t) or something of that type. I'm finding HEAPS of SIMD functions want to return pairs (unpacks in particular): int4 (low, hight) = unpack(someShort8); Currently I have to duplicate everyting: int4 low = unpackLow(someShort8); int4 high = unpackHigh(someShort8); I'm getting really sick of that, it feels so... last millennium. The point of 'proper' multiple return values is to return each value in registers, in its own register type, using exactly the same register assignment pattern as when passing args TO functions. I don't think this causes any side effects to the ABI, since the arg registers are already volatile across function calls in the first place. It just means that the returned-to function can find its return values already conveniently in an appropriate register, avoiding memory access. People argue I should return a tuple, but this isn't really the same, it has hidden implications that complicate the optimisation potential. For instance, tuples have an implicit structure/memory layout which can't be ignored, whereas return values don't have memory allocated, ie, you can't take the address of a return value without first assigning it to some local syntactically. [...] Couldn't you just use ref parameters? Or does the compiler turn them into pointers? ref parameters are pointers by definition. That's not what I'm talking about.
Re: Arbitrary abbreviations in phobos considered ridiculous
Am 07.03.2012, 15:17 Uhr, schrieb Marco Leise marco.le...@gmx.de: Am 07.03.2012, 07:17 Uhr, schrieb Daniel Murphy yebbl...@nospamgmail.com: Derek ddparn...@bigpond.com wrote in message news:op.warmsnem34mv3i@red-beast... On Wed, 07 Mar 2012 03:38:09 +1100, Adam D. Ruppe destructiona...@gmail.com wrote: Why aren't we using real words here? Real words are easier to remember and easier to type. Should we use American or English spelling? Color verses Colour, for example? -- Derek Parnell Melbourne, Australia American. Always. Whatever Java uses. Ok, that *was* a bad idea: http://en.wikipedia.org/wiki/Java#Languages
