Re: Current RDMD, please?
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Walter, could you please update your build scripts to build and include
> rdmd? It's an important tool. Thanks.
> Andrei
That would be great...
But it seems rdmd and my project still aren't getting along (the change in r1315
*does* help though, just not 100%). I'd like to investigate this further and
maybe
provide a patch, but I have some questions about it:
Let me start by outlining [a simplified version of] my project's setup:
My package system is something like this:
module myproj.apps.appA.main; // AppA's 'void main()'
module myproj.apps.appB.main; // AppB's 'void main()'
module myproj.lib.foo; // Foo module, common to both apps
All of the source lives in a "src" subdirectory directly off my project's main
directory. Ie, the modules above correspond to:
{main proj dir}/src/myproj/apps/appA/main.d
{main proj dir}/src/myproj/apps/appB/main.d
{main proj dir}/src/myproj/lib/foo.d
Then there's a build script directly in "{main proj dir}" that tries to build
AppA
by calling:
rdmd -ofbin/appA -Isrc --build-only src/myproj/apps/appA/main.d
Before r1315 (ie the rdmd currently packaged with dmd), rdmd would cd into
"src/myproj/apps/appA/" and would, of course, be unable to find
"src/myproj/apps/appA/main.d" from there.
After r1315 (actually, I'm using the one from r1400), rdmd accessess
"src/myproj/apps/appA/main.d" and gets the deps just fine, since it doesn't cd
anywhere. But then it'll prepend "src/myproj/apps/appA/" to the non-phobos
dependencies and end up telling dmd to compile
"src/myproj/apps/appA/src/myproj/lib/foo.d", which, of course, is a butchered
path.
I can fix this by changing rdmd's (r1400) line #326 from:
myModules[/*rel2abs*/join(rootDir, moduleSrc)] = moduleObj;
to:
myModules[moduleSrc] = moduleObj;
With that change, all is well for me.
So, I would file a ticket with that one-line patch, but I'm not sure if there
was
a specific reason that rootDir should be prepended. Ie, is there some use-case
that would break? If not, then I'll just file that as a ticket, and hopefully it
can be included in the next release. But if not, could you explain what I'm
overlooking so I can try to come up with a patch that would be appropriate?
Re: Current RDMD, please?
Nick Sabalausky wrote: This has been brought up at least a couple times before, and didn't get any official response. Is there something preventing this from happening that maybe I could help out on? I'll take care of it. Sorry about the delays.
Re: Notes on the Phobos style guide
bearophile Wrote: > > * In D, use of auto is recommended unless you want to make a > > specific point by mentioning the type. > > On the other hand code needs to be read too, sometimes by people that have > not written it. In this case seeing the actual types used is often better. So > using "auto" everywhere makes the code reading harder: if you aren't using an > IDE that tells you types, you sometimes need to follow the flux of the > various calls until you find what is the type, or sometimes you need to add > temporary writeln(typeof(x).stringof); inside the code to see what type it > is. This problem is common in dynamic languages. > I agree. Auto hinders understanding. Knowing that we have some fancy type here gives you no knowledge about what's going on. Even with IDE. It also has issues with interoperability. You don't want to pass fancy types to the external code, do you? It also contradicts with the intention to have uniform style because this is an intention to have understandable code.
Re: Phobos incubator project ?
On Monday 16 August 2010 21:20:22 BCS wrote: > (BTW, > Unless you actively cull part, what you are looking for will end up with a > bunch of old projects. Eventually, we're really going to need a system for culling code - especially if pretty much _anyone_ can post there. It may need to have to do with age, or perhaps we can vote on them, and stuff that never gets enough votes will be removed, or maybe it'll just be based on how recently a project has been updated... Anyway, we're going to need some sort of mechanism for culling code, so that it doesn't get full of cruft. And by that same token, we may want a voting system to indicate stuff that people want in Phobos. Obviously, it will always be up to the Phobos devs as to whether something ends up in Phobos or not, but if a lot of people want a particular module or type of module to get into Phobos, then that would be an indication that the Phobos devs should look at adding it (or something similar) to Phobos. Just because something is highly quality does not mean that it should be in Phobos, and even if something is not of the best quality, the fact that it's popular could indicate that we need something like it in Phobos even if the exact code in question needs work. So, as part of setting this up, we are going to need to set up a system of some kind to remove stuff from that should be removed as well as to indicate what stuff likely should be added to Phobos. Overall, I think that this is a great idea, but if it's going to really go somewhere and be useful, it definitely needs to be organized. - Jonathan M Davis
Re: Phobos incubator project ?
Hello BLS, On 16/08/2010 01:55, simendsjo wrote: (still bored?...) No. Think you have made some good points. Scrabble : --Due to the fact that nobody cares about scrabble and scrabble contains x tiny not up-to-date projects the questions remains.. why not having a centralized project ? My question still remains; If it's not what you want, why not turn scrapple into what you are looking for? I'd be more than willing to help. (BTW, Unless you actively cull part, what you are looking for will end up with a bunch of old projects. p.s. it's not scrabble: http://en.wikipedia.org/wiki/Scrapple -- ... <
Re: inline asm plans
SK wrote: On Sat, Aug 14, 2010 at 2:56 PM, SK wrote: Will D try to stay current with new processor instructions or provide just a lowest common denominator? I notice that newer x86 instructions such as CRC32 and POPCNT are not supported by the inline assembler. Well, this one was certainly a dud. ;^) I get the feeling I'm more down on the metal than most folks on this interesting list. Can anyone opine about assembler plans? Some new instructions offer a meaningful performance boost in the right niche, so I hate to think the assembler won't expose them. As of a couple years ago, the inline assembler supported all the opcodes. Intel and AMD keep adding them, though. Just file a bug report on the missing ones.
Re: to!()() & leading/trailing whitespace
On Monday 16 August 2010 16:49:45 bearophile wrote: > Jonathan M Davis: > > A string with whitespace is _not_ a number. > > I will not agree with this this (I am talking about leading/trailing > whitespace only). Regarding the other things you say, I have already given > answers to them. > > Bye, > bearophile Why don't you just use parse()? It allows for leading whitespace, and it's really the function that's intended for turning strings into other types if it's not an exact conversion. - Jonathan M Davis
Re: Unit tests in libraries?
On Mon, 16 Aug 2010 17:38:28 -0700, Walter Bright wrote:
> Mike Linford wrote:
>> Is it working as it should by not including the unit tests with:
>>
>> dmd -unittest -lib mylib.d
>>
>> ?
>
> That should work.
Yeah, I'm not sure what I'm doing wrong. Can someone else try this out?
mylib.d:
1 module mylib;
2
3 void blah()
4 {
5 }
6 unittest
7 {
8assert(false);
9 }
10
test.d:
1 module test;
2
3 import mylib;
4
5 void main()
6 {
7blah();
8 }
9
Makefile:
1 test : mylib.a test.d
2dmd -unittest test.d mylib.a
3
4 mylib.a : mylib.d
5dmd -unittest -lib mylib.d
6
7 clean :
8rm -f test mylib.a *.o
9
--
Mike Linford
Re: Contributing
On 8/16/10, Yao G. wrote: > Are you working on Gregorian documentation? Or the code itself? I've just been (slowly) documenting std.date. I used it for a work project, and hit a similar situation to Pedro: the module was good enough for me, but I had to dive into the source before I knew it even had most the functions that it does. The majority of them have nothing whatsoever, so they don't show up on the website at all. Some of the others aren't obvious as to what the return values mean. For example, do days of the week start at one or zero? That kind of thing. If it were documented, I think it is adequately fit.
Re: inline asm plans
On Mon, 16 Aug 2010, SK wrote: > On Sat, Aug 14, 2010 at 2:56 PM, SK wrote: > > Will D try to stay current with new processor instructions or provide > > just a lowest common denominator? I notice that newer x86 > > instructions such as CRC32 and POPCNT are not supported by the inline > > assembler. > > > > Well, this one was certainly a dud. ;^) I get the feeling I'm more > down on the metal than most folks on this interesting list. > Can anyone opine about assembler plans? Some new instructions offer a > meaningful performance boost in the right niche, so I hate to think > the assembler won't expose them. > -steve Please file an enhancement bug report (at a minimum). Even better would be to take a look at the source and produce a patch adding support for it (iasm.c in the src tree). Adding new codes shouldn't be terribly difficult, but I've not studied that particular part of the code yet. Later, Brad
Re: Notes on the Phobos style guide
On Mon, 16 Aug 2010, Walter Bright wrote: > Jonathan M Davis wrote: > > Obviously, in my own code, I'm just going to code the way that I like, and I > > see no point in any kind of standard D style guide with regards to braces > > and other visual elements to relate primarily to how the code looks rather > > than what it does. > > True, but the idea of having a D style guide goes beyond just having a > standard for Phobos. It fills a vacuum. When there is a reasonable existing > one, lots of organizations will simply adopt it by default rather than go to > the trouble of reinventing their own. A good example of this is Java. While I don't agree with the style -- it has a few things that _really_ annoy me -- it's followed by most developers. Java code tends to look the same everywhere. There's a huge value in this. Python has achieved the same thing, even more so. Partly based on baking structure into the syntax of the language. Again, I don't agree with the style, but I do see the tremendous advantage in having strong consistency in the code base. Later, Brad
Re: Contributing
Pedro Rodrigues wrote: Hello! While working on some pet project using D 2.0, I stumbled on a Phobos module poorly documented (std.date). I had to check the source code to understand what was going on. This made me think, I could help the next guy that stumbles on the same problem, by writing the missing documentation myself. Unfortunately I couldn't figure how am I to submit my contributions. So I was wondering what is the preferred way (if any) to contribute to the D project? And I would also like to suggest a development model, like in github, where anyone can fork the project, and work on his fork. Then the maintainer of the main fork, can easily merge in the work done in other forks, if it pleases him. I believe this would make a lot easier to contribute to the project. Cheers Pedro, Welcome and thanks for your intent to contribute. Discussing your ideas here, submitting patches to bugzilla (d.puremagic.com/issues), and creating and maintaining your own project on your website or at dsource.org should be enough to attract everybody's attraction. Andrei
Re: Contributing
On Mon, 16 Aug 2010 20:18:28 -0500, Adam Ruppe wrote: I started doing this too, and am planning to commit it for the next release. I haven't finished it though. Are you working on Gregorian documentation? Or the code itself? I was trying to do an improvement following the original Boost date_time, but I gave up when I had to implement that faux-IEEE754 integer that handles infinities (+ and -), and NANs. It was just too much :( And it was only the DateTime component, I still hadn't checked the remaining classes. -- Yao G.
Re: Contributing
Adam Ruppe wrote: I started doing this too, and am planning to commit it for the next release. I haven't finished it though. If you email your modified copy of date.d to me (destructionator (at) gmail.com), I'll integrate your changes with mine and commit it to Phobos for you. There seems to be growing interest in std.date and the embryonic std.gregorian as of late. Allow me to paste something I wrote to the phobos dev list: Thanks for your work, Jonathan. Our decision after the issue with Tango's date and time was to use Boost's. I'd started std.gregorian as a seed of a port of Boost's date and time, in the hope that someone will continue it. Jeff Garland (Boost's date/time author) has been very supportive in the matter. I very strongly suggest to stick with copying Boost's or C++0x's date and time facilities, unless we find some clearly superior ways facilitated by D's features. Developing our own date/time library from scratch risks of being at best just as capable as Boost/C++0x but guaranteed unfamiliar to everyone. To further elaborate, dates and times are a simple enough topic that many people might try their hand at designing. Yet today's designs did arrive at sufficient sophistication to prompt us to try copying a strong existing design instead of coming up with one from scratch. Andrei
Re: inline asm plans
On Sat, Aug 14, 2010 at 2:56 PM, SK wrote: > Will D try to stay current with new processor instructions or provide > just a lowest common denominator? I notice that newer x86 > instructions such as CRC32 and POPCNT are not supported by the inline > assembler. > Well, this one was certainly a dud. ;^) I get the feeling I'm more down on the metal than most folks on this interesting list. Can anyone opine about assembler plans? Some new instructions offer a meaningful performance boost in the right niche, so I hate to think the assembler won't expose them. -steve
Re: to!()() & leading/trailing whitespace
Jonathan M Davis wrote: On Monday, August 16, 2010 16:49:45 bearophile wrote: Jonathan M Davis: A string with whitespace is _not_ a number. I will not agree with this this (I am talking about leading/trailing whitespace only). Regarding the other things you say, I have already given answers to them. Bye, bearophile Well, while it may not be what you want, writing a wrapper which calls strip() would be easy to do. It's more complicated than that. readf works with arbitrary input streams, so there would be need for a skipWhitespace() routine. Andrei
Re: Current RDMD, please?
Nick Sabalausky wrote:
The RDMD included with DMD is still 20090902, which is two revisions
out-of-date.
The lack of the fix in r1315 ("Made relative paths searched from the main
file, not the current dir") is a breaker for using RDMD with my projects,
which is particularly bad since xfbuild (my other go-to build tool) seems to
have become incompatible with newer D2s (Ie, certain basic things that work
with newer DMDs get choked on by xfbuild). I know I can compile the latest
RDMD myself, but anyone else compiling my stuff (or using my stbuild tool)
has to do the same.
So can we please get the current RDMD included with the next DMD
(particularly D2) release?
This has been brought up at least a couple times before, and didn't get any
official response. Is there something preventing this from happening that
maybe I could help out on?
Walter, could you please update your build scripts to build and include
rdmd? It's an important tool. Thanks.
Andrei
Re: Notes on the Phobos style guide
I think Jonathan was talking about the entire community, not a single project. It's impossible for all people to accept a unified standard, everyone has their own style and they'll most probably keep it that way. What matters is consistency. So if you have a certain way of coding, be consistent about it throughout your project. On Tue, Aug 17, 2010 at 3:38 AM, bearophile wrote: > Jonathan M Davis: > > > I see little no value in trying to enforce any kind of > > coding standard on the D community as a whole, > > If your program is partially composed by several modules written by > different programmers, that you have found on the net (like from dsource), > you will not appreciate to see your program as an Harlequin written in ten > widely different coding styles. A more uniform coding style helps you see > your program as a single whole instead of as a puzzle, and you will need > less time to modify, debug and improve it. If you don't see the advantage of > this for your D/Python programs then maybe it's because you haven't done > this yet :-) > > Bye, > bearophile >
Re: Notes on the Phobos style guide
> If you don't see the advantage of this for your D/Python programs then maybe > it's because you haven't done this yet :-) Sorry, my manners need to be improved. bearophile
Re: to!()() & leading/trailing whitespace
bearophile wrote: This post is about this enhancement request of mine that recently David Simcha has closed as wontfix: http://d.puremagic.com/issues/show_bug.cgi?id=4165 [snip] Phobos functions are meant as the most simpler bricks, that you may compose to perform more complex operations: this is generally true and good, but Python shows that when two or few operations are frequently done attached to each other, it's good to put inside the std lib something the performs the composed thing in one go, because it helps chunk the code and makes the code shorter and more readable, and decreases the chance for bugs. When I read numbers from files I will need to use to!int(txt.strip()) often. I don't feel very strongly about this (in particular e.g. I do allow leading whitespace for floating-point parsing). My only problem is that sometimes people _don't_ want to ignore trailing whitespace, which becomes quite difficult. But then I guess that's a rare case. Andrei
Re: to!()() & leading/trailing whitespace
Jonathan M Davis: > Well, while it may not be what you want, writing a wrapper which calls > strip() > would be easy to do. It's what I will probably do... Bye, bearophile
Re: Notes on the Phobos style guide
Jonathan M Davis: > I see little no value in trying to enforce any kind of > coding standard on the D community as a whole, If your program is partially composed by several modules written by different programmers, that you have found on the net (like from dsource), you will not appreciate to see your program as an Harlequin written in ten widely different coding styles. A more uniform coding style helps you see your program as a single whole instead of as a puzzle, and you will need less time to modify, debug and improve it. If you don't see the advantage of this for your D/Python programs then maybe it's because you haven't done this yet :-) Bye, bearophile
Re: Current RDMD, please?
Nick Sabalausky: > which is particularly bad since xfbuild (my other go-to build tool) seems to > have become incompatible with newer D2s (Ie, certain basic things that work > with newer DMDs get choked on by xfbuild). If/once xfbuild shows to be good enough and easy enough to use (I have never used it so far), it may be added to the standard dmd distribution. Bye, bearophile
Re: Contributing
I started doing this too, and am planning to commit it for the next release. I haven't finished it though. If you email your modified copy of date.d to me (destructionator (at) gmail.com), I'll integrate your changes with mine and commit it to Phobos for you.
Contributing
Hello! While working on some pet project using D 2.0, I stumbled on a Phobos module poorly documented (std.date). I had to check the source code to understand what was going on. This made me think, I could help the next guy that stumbles on the same problem, by writing the missing documentation myself. Unfortunately I couldn't figure how am I to submit my contributions. So I was wondering what is the preferred way (if any) to contribute to the D project? And I would also like to suggest a development model, like in github, where anyone can fork the project, and work on his fork. Then the maintainer of the main fork, can easily merge in the work done in other forks, if it pleases him. I believe this would make a lot easier to contribute to the project. Cheers
Current RDMD, please?
The RDMD included with DMD is still 20090902, which is two revisions
out-of-date.
The lack of the fix in r1315 ("Made relative paths searched from the main
file, not the current dir") is a breaker for using RDMD with my projects,
which is particularly bad since xfbuild (my other go-to build tool) seems to
have become incompatible with newer D2s (Ie, certain basic things that work
with newer DMDs get choked on by xfbuild). I know I can compile the latest
RDMD myself, but anyone else compiling my stuff (or using my stbuild tool)
has to do the same.
So can we please get the current RDMD included with the next DMD
(particularly D2) release?
This has been brought up at least a couple times before, and didn't get any
official response. Is there something preventing this from happening that
maybe I could help out on?
Re: Unit tests in libraries?
Mike Linford wrote: Is it working as it should by not including the unit tests with: dmd -unittest -lib mylib.d ? That should work.
Re: Unit tests in libraries?
On Mon, 16 Aug 2010 11:22:50 -0700, Walter Bright wrote: > Mike Linford wrote: >> On Mon, 16 Aug 2010 10:26:46 -0700, Walter Bright wrote: >> >>> Mike Linford wrote: The unit test does not get run when compiled as: dmd -lib mylib.d dmd main.d mylib.a But does get run when compiled as dmd main.d mylib.d >>> >>> You need to compile with -unittest to run them. >> >> Also, the following creates a library that does run the unit tests: dmd >> -c -unittest mylib.d >> ar -rc mylib.a mylib.o >> dmd -unittest main.d mylib.a > > Right, that's working as it should. Is it working as it should by not including the unit tests with: dmd -unittest -lib mylib.d ? -- Mike Linford
Re: Notes on the Phobos style guide
Jonathan M Davis wrote: Obviously, in my own code, I'm just going to code the way that I like, and I see no point in any kind of standard D style guide with regards to braces and other visual elements to relate primarily to how the code looks rather than what it does. True, but the idea of having a D style guide goes beyond just having a standard for Phobos. It fills a vacuum. When there is a reasonable existing one, lots of organizations will simply adopt it by default rather than go to the trouble of reinventing their own.
Re: to!()() & leading/trailing whitespace
On Monday, August 16, 2010 16:49:45 bearophile wrote: > Jonathan M Davis: > > A string with whitespace is _not_ a number. > > I will not agree with this this (I am talking about leading/trailing > whitespace only). Regarding the other things you say, I have already given > answers to them. > > Bye, > bearophile Well, while it may not be what you want, writing a wrapper which calls strip() would be easy to do. - Jonathan M Davis
Re: The Status of Const
On 2010-08-16 19:06:56 -0400, "Simen kjaeraas" said:
Uhm, it works in D:
class C {}
class D : C {}
void main( ) {
D[] a;
C[] b = a;
}
Then that's a bug because it'd allow you to do this:
void main() {
D[] a = new D[1];
C[] b = a;
b[0] = new C;
// what is the type of a[0] now? Certainly not a D.
}
This would be fine however:
const(C)[] b = a;
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Notes on the Phobos style guide
On Monday, August 16, 2010 15:59:14 bearophile wrote: > Jonathan M Davis: > > Obviously, in my own code, I'm just going to code the way that I like, > > and I see no point in any kind of standard D style guide with regards to > > braces and other visual elements to relate primarily to how the code > > looks rather than what it does. > > Often you need to modify legacy C/C++/Java code, or you need to work in a > team, in such very common situations it's often better to follow some > style standard. Well, yes, but if I have a choice, I'm going to code in the manner which I like best - like where to place braces and where to put spaces and how many. It's not like I code in obfuscated D (or C/C++/Java/whatever). I think that most people who are consistent in their coding style produce understandable code. The problem is when you have to share or when you have a really bizarre style that no one else understands. I see little no value in trying to enforce any kind of coding standard on the D community as a whole, just like I see no value in doing it to the C++ community. Now, a particular _project_ - such as Phobos can benefit from a particular style since you're dealing with a group of contributors, but with my own code - even if I make it publicly available - there shouldn't be any problem in coding in my own style as long as it's reasonably readable. It's only when dealing with projects that it makes sense to enforce any kind of coding standard. - Jonathan M Davis
Re: to!()() & leading/trailing whitespace
Jonathan M Davis: > A string with whitespace is _not_ a number. I will not agree with this this (I am talking about leading/trailing whitespace only). Regarding the other things you say, I have already given answers to them. Bye, bearophile
Re: The Status of Const
On Mon, 16 Aug 2010 19:06:56 -0400, Simen kjaeraas
wrote:
Jonathan M Davis wrote:
On Monday, August 16, 2010 15:31:23 Steven Schveighoffer wrote:
We can move onto the next test:
Given:
class C {}
class D : C {}
convert Array!D into Array!(const C)
OK, maybe this is a more advanced test :)
I'd be happy with just proper factoring of const to be honest.
Um, I don't think that I've ever seen that work in _any_ language, and
I'm not
sure that it would be a good thing if it did. Array!D is a completely
different
type from Array!C or Array!(const C). I could see an argument that
Array!D
should work as Array!(const D), but that seems off to me. Converting
Array!D to
const (Array!D) should work though.
Uhm, it works in D:
class C {}
class D : C {}
void main( ) {
D[] a;
C[] b = a;
}
Yes, I was about to say that except that is a bug kind of. The type
system should only allow casting D[] to const(C)[].
See http://d.puremagic.com/issues/show_bug.cgi?id=2095
But aside from that, the test is invalid, I don't think D* can implicitly
cast to C* (I'm not sure). This might be a built-in array-only thing.
The compiler is going to be hard-pressed to get that one right anyways, as
it involves changing types as Jonathan said.
This kind of thing is tricky to get right.
BTW, I thought about it more, and I don't think
Rebindable!(const(Array!V)) is going to work. The public interface that
rebindable exposes is the const version, and you want to expose the const
version only for the references, and expose the mutable version for the
values. Rebindable only allows reassigning the whole struct at once.
I feel more and more strongly that this has to be a compiler solution. A
library solution may eventually be possible, but it's going to be very
nasty/tricky to write. I wouldn't be surprised if using a library tail
const type adds 10K to the executable size for each type it's used on...
-Steve
Re: Notes on the Phobos style guide
On Mon, 16 Aug 2010 19:29:27 -0400, Adam Ruppe wrote: Besides, worst case, you have to scroll up a few lines to see the original type, but it is there if you need it. It isn't like a dynamic language where the type can be anything passed in and can change at random at any time. It is set in one place and stays consistent. Or, you use an ide which tells you the type :) For modification, it makes things easier since you don't need to repeat yourself. You can make a change in one place, and that change automatically propagates. Again, unlike dynamic languages, the type is still consistent: if the change breaks things down the line, the compiler will tell you, whether you use auto or not. This is the most awesome thing about auto. It is one of the best features of D IMO.
Re: Notes on the Phobos style guide
On 8/16/10, bearophile wrote: > 'auto' in C++0x is a good and useful feature, just as it is useful in D, but > as I have explained it has real risks, so it must be used with moderation, > if you use it everywhere in the code, your code becomes harder to understand > and modify. I see it as the opposite: it is about the same to understand, and much easier to modify. For understanding, the type is determined on the right side of the thing anyway, and is usually plainly obvious, or if not, the type doesn't really matter. Examples of the former are new statements or literals, and examples of the latter are a lot of the fancy ranges' return values. Besides, worst case, you have to scroll up a few lines to see the original type, but it is there if you need it. It isn't like a dynamic language where the type can be anything passed in and can change at random at any time. It is set in one place and stays consistent. For modification, it makes things easier since you don't need to repeat yourself. You can make a change in one place, and that change automatically propagates. Again, unlike dynamic languages, the type is still consistent: if the change breaks things down the line, the compiler will tell you, whether you use auto or not.
Re: The Status of Const
Jonathan M Davis wrote:
On Monday, August 16, 2010 15:31:23 Steven Schveighoffer wrote:
We can move onto the next test:
Given:
class C {}
class D : C {}
convert Array!D into Array!(const C)
OK, maybe this is a more advanced test :)
I'd be happy with just proper factoring of const to be honest.
Um, I don't think that I've ever seen that work in _any_ language, and
I'm not
sure that it would be a good thing if it did. Array!D is a completely
different
type from Array!C or Array!(const C). I could see an argument that
Array!D
should work as Array!(const D), but that seems off to me. Converting
Array!D to
const (Array!D) should work though.
Uhm, it works in D:
class C {}
class D : C {}
void main( ) {
D[] a;
C[] b = a;
}
--
Simen
Re: to!()() & leading/trailing whitespace
On Monday, August 16, 2010 15:35:51 bearophile wrote: > This post is about this enhancement request of mine that recently David > Simcha has closed as wontfix: > http://d.puremagic.com/issues/show_bug.cgi?id=4165 > > This topic is about a small Phobos thing, it's not about large complex > things as the const system. But it's relevant because I have hundreds of > Python scripts (and many small D1 programs) that essentially load some > numbers from textual files, process them, and write the numbers in other > textual files. My textual files are often small, but I have many of them, > and I like to see them processed quickly and safely, and I like to write > those little programs in a short time. So reading numbers from a text file > is an essential operation for me. And when I read textual files it's > common to have leading newlines (whitespace) behind numbers. > [snip] A string with whitespace is _not_ a number. I can see why that would be problematic when you don't care about the whitespace, but you're converting the whole string, not just the numeric part. Using strip() is an extremely trivial workaround, and if you don't like that, there's always parse() which will strip out the whitespace itself. to() is for exact conversions, and whitespace is non- numeric. If you want to parse a string, then use parse(). I totally agree with David on this one. All the tools that you need are there. - Jonathan M Davis
Re: Notes on the Phobos style guide
Jonathan M Davis: > Obviously, in my own code, I'm just going to code the way that I like, and I > see > no point in any kind of standard D style guide with regards to braces and > other > visual elements to relate primarily to how the code looks rather than what it > does. Often you need to modify legacy C/C++/Java code, or you need to work in a team, in such very common situations it's often better to follow some style standard. And even if you write D code on your own, you are not truly alone, you are part of the D community of programmers. If you write a good module you may want to give it to the D community. Part of the success of Python comes from the ease to find free (as in beer) already written modules able to do almost everything that you can just add to your own programs, usually with little or no troubles. So your Python program comes from the collection of many modules written by other people. So even if you are writing code on your own, it's a bit like your 'team' is the whole Python (and in future hopefully D2 too) community. This is why the uniform style of writing Python code is good for the development of the whole community. I think Walter has written the D style page (see below) because he has understood this some years ago. > And I'm not aware of any official anything > anywhere that talks about what is and isn't considered good practice in D. http://www.digitalmars.com/d/2.0/dstyle.html Bye, bearophile
Re: The Status of Const
On Monday, August 16, 2010 15:31:23 Steven Schveighoffer wrote:
> We can move onto the next test:
>
> Given:
>
> class C {}
>
> class D : C {}
>
> convert Array!D into Array!(const C)
>
> OK, maybe this is a more advanced test :)
>
> I'd be happy with just proper factoring of const to be honest.
Um, I don't think that I've ever seen that work in _any_ language, and I'm not
sure that it would be a good thing if it did. Array!D is a completely different
type from Array!C or Array!(const C). I could see an argument that Array!D
should work as Array!(const D), but that seems off to me. Converting Array!D to
const (Array!D) should work though.
In any case, converting a collection of one type to a collection of another
type
is something that I've never seen done, and I'm not sure that it would be a
desirable feature ultimately. I'm not sure that it should _not_ be possible,
but
it would certainly make me nervous. I'd really have to think about the
implications before I agreed that it was a good idea.
- Jonathan M Davis
Re: Notes on the Phobos style guide
Andrei Alexandrescu: > [citation needed] > A cursory googling didn't find many discussions. The people that have designed C++0x are surely smart and expert, but they have done some mistakes: - the lambda is WAY over-engineered; - and the R-value references are useful but they look too much hard for most normal programmers (they may be useful for core library writers). I will not appreciate R-value references in D2/D3. 'auto' in C++0x is a good and useful feature, just as it is useful in D, but as I have explained it has real risks, so it must be used with moderation, if you use it everywhere in the code, your code becomes harder to understand and modify. Few discussions regarding the 'var' of C#: http://stackoverflow.com/questions/545616/why-would-var-be-a-bad-thing http://stackoverflow.com/questions/633474/c-do-you-use-var http://stackoverflow.com/questions/41479/use-of-var-keyword-in-c I am sure C++0x style guides (like Google ones) will warn against an excessive usage of 'auto'. Bye, bearophile
Re: Notes on the Phobos style guide
This is, unfortunately, the sort of thing that can get pretty opinionated, and there are plenty of people who hate having to write code in any style other than their own, but unfortunately, you do sometimes need at least some sort of stylistic guidelines or things can become a mess. On Monday, August 16, 2010 15:15:47 bearophile wrote: > Few comments of mine about this, written by Andrei: > http://lists.puremagic.com/pipermail/phobos/2010-August/001757.html > > > * Generally the prevalent Phobos (and I hope D) style is to declare > > local values as late as possible. > > Good. [snip] Personally, I really hate having all of the variables declared at the top of the function and consider it bad style. You'll have fewer bugs if you can avoid declaring variables before you're actually read to initialize it with a real value (though D's default initialization of all variables mitigates this somewhat). > > > * In D, use of auto is recommended unless you want to make a > > specific point by mentioning the type. > > This is where I don't agree. [snip] I'm increasingly in the pro-auto camp, but I do think that you need to use it wisely. In most cases, I think that it's quite clear what type you're dealing with, but if there really is going to be an issue with that, then the exact type should be used. Overall, I do think that auto should be the default - particularly for smaller functions where it's really easy to see what's going on - but there are exceptions. > > * Phobos currently uses full bracing after if, while etc. I've tried to > > follow that but on occasion I slip. I'm not sure whether we should > > enforce such rules; this might be a good time to discuss that. > > I don't have a definite opinion on this. I am just glad Python has *solved* > this class of problems, and it removes some braces-related bugs. Personally, I _like_ having braces in D, but I also dislike pointless braces. I usually only put them if the condition spans more than one line or if the body spans more than one line (whether it's one statement or multiple). I hate having to put extra braces, but I've had to work in shops before where braces were always required. > > * Generally I encourage economy of vertical space, e.g. > > auto imp = new File.Impl(fp, 1, host ~ ":" ~ to!string(port)); > > f.p = imp; > > => > > f.p = new File.Impl(fp, 1, host ~ ":" ~ to!string(port)); > > It's a matter of readability too. > I generally don't like this: > > if (...) bar(); > > I generally prefer (as the Python PEP 8 suggests): > > if (...) > bar(); > > But in some situations (for example when there are many small short > successive ifs), the one-line version is OK: > > if (cond1) bar(); > if (condi2)baz(); > if (co3) spam(); > if (condtion4) x++; I hate one line if statements, but I don't like pointless variables either. I also dislike the extra spacing that you have around your parens. I do find it interesting, however, that Andrei lists both always using braces and saving vertical space, since they're pretty contradictory. In any case, ultimately, Phobos likely does need some sort of simple style guide that ensures that the code is at least relatively uniform, but it's pretty much a guarantee that whatever is picked is going to annoy at least some portion of the folks that have to deal with it. But ultimately, it only really matters to the Phobos devs, since they're the ones who are going to be working on the code. Obviously, in my own code, I'm just going to code the way that I like, and I see no point in any kind of standard D style guide with regards to braces and other visual elements to relate primarily to how the code looks rather than what it does. As for stuff like auto, however, I'd argue that that isn't entirely a stylistic issue. Part of that is a question of good practices rather than having something that looks nice and is readable. And I'm not aware of any official anything anywhere that talks about what is and isn't considered good practice in D. We should probably get something like that at some point as some of what should go there becomes clear. Though I'm not sure whether there's enough collective experience with D2 at this point (especially considering that it's only recently stop having massive changes to it) to really get much of a list together that's particularly specific to D rather than what you'd do in similar languages like C++ or C#. - Jonathan M Davis
Re: Phobos incubator project ?
Hello BLS, On 16/08/2010 02:59, BCS wrote: Hello BLS, Hello BCS, :) yeah know of course about scrapple. wouldn't it be better if f.i. Units are part of a "Centralized" bigger Incubator project, instead of being a bit lost somewhere on dsource? What I'm suggesting is that scrappe *be* a centralized big incubator project, instead of being a bit lost somewhere on dsource. Bjoern -- ... <
to!()() & leading/trailing whitespace
This post is about this enhancement request of mine that recently David Simcha
has closed as wontfix:
http://d.puremagic.com/issues/show_bug.cgi?id=4165
This topic is about a small Phobos thing, it's not about large complex things
as the const system. But it's relevant because I have hundreds of Python
scripts (and many small D1 programs) that essentially load some numbers from
textual files, process them, and write the numbers in other textual files. My
textual files are often small, but I have many of them, and I like to see them
processed quickly and safely, and I like to write those little programs in a
short time. So reading numbers from a text file is an essential operation for
me. And when I read textual files it's common to have leading newlines
(whitespace) behind numbers.
David has closed 4165 because:
- It's by design (it's mentioned in the docs of std.conv). But I don't care of
this, I think this it's a wrong design.
- There's a trivial workaround: this is true, but you need to remember to use
this workaround, it may cause bugs (bugs == the program doesn't work), and I
don't see the point in using a workaround very often in my code, I prefer to!()
to do that by itself.
In practice sometimes I use printf() in those D scripts to print many numbers
because it's much faster than writeln(). So I can write and use a more
efficient function that converts strings to numbers, but I'd like to need
Phobos only for such basic and common operation.
Possible disadvantages of a to!int() (and similar to!double(), etc) that
ignores leading and trailing whitespace:
It introduces bugs, because it accepts a more sloppy input: from my experience
this is not true, in Python int() and float() ignore the leading/trailing
whitespace and in years I don't remember it ever causing bugs to me:
>>> int(" -125\n")
-125
>>> float(" 6.3e6\t")
630.0
Phobos functions are meant as the most simpler bricks, that you may compose to
perform more complex operations: this is generally true and good, but Python
shows that when two or few operations are frequently done attached to each
other, it's good to put inside the std lib something the performs the composed
thing in one go, because it helps chunk the code and makes the code shorter and
more readable, and decreases the chance for bugs. When I read numbers from
files I will need to use to!int(txt.strip()) often.
Bye,
bearophile
Re: The Status of Const
On Mon, 16 Aug 2010 18:12:35 -0400, Tomek Sowiński wrote:
Dnia 16-08-2010 o 17:17:32 Steven Schveighoffer
napisał(a):
* Perhaps a good starting point is to look at std.container.SList and
see how const(SList!T) can be manipulated.
We can start simpler than that. Give a struct:
struct Array(V)
{
uint length;
V *v;
}
How can we turn Array!V into Array!(const(V)) implicitly...
This will duplicate array tail-const, and be essential to making
tail-const ranges.
It should be a good starting test for any library/compiler solution.
Nice litmus test. I thought about it for a while and came up with:
Array!int arr = ... ;
Rebindable!(const Array!V) r = arr;
Wait, is the length mutable in that type? If so, that's better than I
thought Rebindable could do...
We can move onto the next test:
Given:
class C {}
class D : C {}
convert Array!D into Array!(const C)
OK, maybe this is a more advanced test :)
I'd be happy with just proper factoring of const to be honest.
It actually compiles if you remove the template constraint off
Rebindable. But tail const/immutable is generally desired so you'd end
up with rebindable everywhere making variable manipulation cumbersome,
the code less auditable, giving easy counter-arguments in language wars
("D must resort to casts, so much for the type system revolution,
haha"), etc.
Naming is subject to debate. I think with some functions to surround it,
and better naming, Rebindable can be quite usable. With aliases, you have
the power to shorten anything.
e.g.:
template tconst(T)
{
alias Rebindable!(const T) tconst;
}
tconst!T is pretty much as easy as @tail const(T). But the implicit
conversion *has* to be there.
Plus, there's the merriness with shared (tail-shared structures, anyone?
and of course you'd want a tail-const view on it at some point, etc).
tail shared is similar to tail const. But implicit conversions are not
there. It's more like tail-immutable.
Rebindable (this name doesn't scale) would basically have to reimplement
all of D's type conversions via operator overloading, template
constraints, static ifs, and blunt casts. Like as if implementing all
this in a compiler alone wasn't hard enough...
I agree, compiler support would be easiest on the user. In fact, compiler
support to make rebindable possible may be more difficult than compiler
support for tail-X since tail-X already works for other items.
-Steve
Re: Notes on the Phobos style guide
bearophile wrote: Few comments of mine about this, written by Andrei: http://lists.puremagic.com/pipermail/phobos/2010-August/001757.html * Generally the prevalent Phobos (and I hope D) style is to declare local values as late as possible. Good. Defining variables at the top of the function/method is positive because it makes the code tidy and it's easy to see in a moment all variables used (Pascal-like languages nearly enforce this). But defining them as close as possible to their usage point has usually bigger advantages that I don't list here. But as usual all rules need to be used in a flexible way. On the other hand global variables/constants are global both in scope and their definition order doesn't matter, so I think that putting them all at the top of the module is better. * In D, use of auto is recommended unless you want to make a specific point by mentioning the type. This is where I don't agree. "auto" is very handy. When you have complex types coming out of lazy map, filter, etc, auto becomes very important, writing code becomes simpler. On the other hand code needs to be read too, sometimes by people that have not written it. In this case seeing the actual types used is often better. So using "auto" everywhere makes the code reading harder: if you aren't using an IDE that tells you types, you sometimes need to follow the flux of the various calls until you find what is the type, or sometimes you need to add temporary writeln(typeof(x).stringof); inside the code to see what type it is. This problem is common in dynamic languages. So 'auto' can be abused, online you can find plenty of discussions about disadvantages of 'auto' in C++0x and 'var' in C#. I like the D 'auto' and I use it, but in my opinion it's bad to use it everywhere and to encourage too much its usage. D lacks the flexibility of a dynamic language, so it's not positive to hide too much the types of variables from the person that reads the code. [citation needed] A cursory googling didn't find many discussions. Andrei
Notes on the Phobos style guide
Few comments of mine about this, written by Andrei: http://lists.puremagic.com/pipermail/phobos/2010-August/001757.html > * Generally the prevalent Phobos (and I hope D) style is to declare > local values as late as possible. Good. Defining variables at the top of the function/method is positive because it makes the code tidy and it's easy to see in a moment all variables used (Pascal-like languages nearly enforce this). But defining them as close as possible to their usage point has usually bigger advantages that I don't list here. But as usual all rules need to be used in a flexible way. On the other hand global variables/constants are global both in scope and their definition order doesn't matter, so I think that putting them all at the top of the module is better. > * In D, use of auto is recommended unless you want to make a > specific point by mentioning the type. This is where I don't agree. "auto" is very handy. When you have complex types coming out of lazy map, filter, etc, auto becomes very important, writing code becomes simpler. On the other hand code needs to be read too, sometimes by people that have not written it. In this case seeing the actual types used is often better. So using "auto" everywhere makes the code reading harder: if you aren't using an IDE that tells you types, you sometimes need to follow the flux of the various calls until you find what is the type, or sometimes you need to add temporary writeln(typeof(x).stringof); inside the code to see what type it is. This problem is common in dynamic languages. So 'auto' can be abused, online you can find plenty of discussions about disadvantages of 'auto' in C++0x and 'var' in C#. I like the D 'auto' and I use it, but in my opinion it's bad to use it everywhere and to encourage too much its usage. D lacks the flexibility of a dynamic language, so it's not positive to hide too much the types of variables from the person that reads the code. > * Phobos currently uses full bracing after if, while etc. I've tried to > follow that but on occasion I slip. I'm not sure whether we should > enforce such rules; this might be a good time to discuss that. I don't have a definite opinion on this. I am just glad Python has *solved* this class of problems, and it removes some braces-related bugs. > * Generally I encourage economy of vertical space, e.g. > auto imp = new File.Impl(fp, 1, host ~ ":" ~ to!string(port)); > f.p = imp; > => > f.p = new File.Impl(fp, 1, host ~ ":" ~ to!string(port)); It's a matter of readability too. I generally don't like this: if (...) bar(); I generally prefer (as the Python PEP 8 suggests): if (...) bar(); But in some situations (for example when there are many small short successive ifs), the one-line version is OK: if (cond1) bar(); if (condi2)baz(); if (co3) spam(); if (condtion4) x++; Bye, bearophile
Re: The Status of Const
Dnia 16-08-2010 o 17:17:32 Steven Schveighoffer
napisał(a):
* Perhaps a good starting point is to look at std.container.SList and
see how const(SList!T) can be manipulated.
We can start simpler than that. Give a struct:
struct Array(V)
{
uint length;
V *v;
}
How can we turn Array!V into Array!(const(V)) implicitly...
This will duplicate array tail-const, and be essential to making
tail-const ranges.
It should be a good starting test for any library/compiler solution.
Nice litmus test. I thought about it for a while and came up with:
Array!int arr = ... ;
Rebindable!(const Array!V) r = arr;
It actually compiles if you remove the template constraint off Rebindable.
But tail const/immutable is generally desired so you'd end up with
rebindable everywhere making variable manipulation cumbersome, the code
less auditable, giving easy counter-arguments in language wars ("D must
resort to casts, so much for the type system revolution, haha"), etc.
Plus, there's the merriness with shared (tail-shared structures, anyone?
and of course you'd want a tail-const view on it at some point, etc).
Rebindable (this name doesn't scale) would basically have to reimplement
all of D's type conversions via operator overloading, template
constraints, static ifs, and blunt casts. Like as if implementing all this
in a compiler alone wasn't hard enough...
Tomek
Re: To avoid some 32=>64 bit user code port bugs
Or size_t and ptrdiff_t could be made to be built-in types. (?) There's no justification for that. A proper way to define a strong typedef on the other hand is something that is really needed.
Re: Andrei's Google Talk
On 16.08.2010 23:10, lurker wrote: > Johannes Pfau Wrote: > > Fixing problems is good, but when creating documentation the main focus is on > communicating ideas. All kinds of fancy colors just distract people. I like > default Phobos docs. It's hard to find something as simple from other > language communities. The C++ documentation sucks so much that I mostly read > dead tree books. And I think simple macros are better than tons of semicolon > rules. Well different people, different opinions I guess. The phobos documentation layout really does a great job at being simple and still good-looking. But when heavy template usage is documented (std.algorithm) I sometimes feel lost (in std.algorithm 'Until' is an example for that). I think some color there is helpful. But the great thing about ddoc is you can have both. The semicolon rules are important for xml - I don't want semicolons in my xml output ;-) (Though it could be argued whether xml output is needed at all) > > I meant that one or candydoc. yes candydoc is nice, but AFAIK it's not maintained since quite some time. -- Johannes Pfau
Re: Andrei's Google Talk
Mon, 16 Aug 2010 17:10:12 -0400, lurker wrote: > Johannes Pfau Wrote: > >> On 16.08.2010 22:36, lurker wrote: >> > >> > This is unbelievable douchebaggery. The default ddoc IS good enough >> > for most of us. There is simply no need for more complex tools. I >> > think ddoc hits the sweet spot here by providing semi-professional >> > looking html documents. Like someone said earlier, you can always >> > spent a week worth of time creating a better tool for document >> > generation. >> > >> > Doxygen STILL doesn't support D. What does this tell? It tells that >> > C++ is crappy for software development. The millions of C++ users >> > haven't been able to write a docgen support for D. It's just not >> > possible. OTOH a qualified compiler veteran such as Walter wrote a >> > better tool in less than a week, blindfolded. >> >> What's the point of this post? >> I never wanted to replace ddoc in any way - the syntax is the best >> documentation syntax that I've seen, the WYSIWYG ideology is great and >> it's great that ddoc can output to different formats. If it sounded >> like I was flaming or something, I did not want to. (I agree, the last >> point about <,> is quite hypothetical) > > Whatever. I feel insulted. :-( And they try to convince themselves that I'm the troll..
Re: To avoid some 32=>64 bit user code port bugs
On Aug 17, 10 04:30, Trass3r wrote: Isn't typedef being deprecated? Which brings us back to the task of augmenting the library-based alternative. I already started 2 threads about this. Or size_t and ptrdiff_t could be made to be built-in types. (?)
Re: Andrei's Google Talk
Johannes Pfau Wrote: > On 16.08.2010 22:36, lurker wrote: > > > > This is unbelievable douchebaggery. The default ddoc IS good enough for > > most of us. There is simply no need for more complex tools. I think ddoc > > hits the sweet spot here by providing semi-professional looking html > > documents. Like someone said earlier, you can always spent a week worth of > > time creating a better tool for document generation. > > > > Doxygen STILL doesn't support D. What does this tell? It tells that C++ is > > crappy for software development. The millions of C++ users haven't been > > able to write a docgen support for D. It's just not possible. OTOH a > > qualified compiler veteran such as Walter wrote a better tool in less than > > a week, blindfolded. > > What's the point of this post? > I never wanted to replace ddoc in any way - the syntax is the best > documentation syntax that I've seen, the WYSIWYG ideology is great and > it's great that ddoc can output to different formats. If it sounded like > I was flaming or something, I did not want to. (I agree, the last point > about <,> is quite hypothetical) Whatever. I feel insulted. :-( > > But there are little problems with ddoc - I mentioned a few, some more > are already known and some of these might even exist in doxygen as well. > (I don't know doxygen and I always thought it's generated documentation > looks ugly. I only know the msdn / ndoc / qooxdoo.org api documentation > which IMHO beat doxygen) Sure most of these issues are often not > important. But if it's possible why not fix these? Why is spending one > week (of my time) to enhance ddoc (and fix the known bugs, I want to > provide a fix for the known problem with stray parenthesis in the next > few days) a bad thing? Fixing problems is good, but when creating documentation the main focus is on communicating ideas. All kinds of fancy colors just distract people. I like default Phobos docs. It's hard to find something as simple from other language communities. The C++ documentation sucks so much that I mostly read dead tree books. And I think simple macros are better than tons of semicolon rules. > > BTW: what do you consider to be "default ddoc"? I agree that the phobos > documentation is fine, but there is no default ".ddoc" file shipped with > dmd and the documentation generated without a special .ddoc file is not > that great. I meant that one or candydoc.
Re: readf for the novice
Sean Kelly wrote:
> Ali Çehreli Wrote:
>> int i;
>> int j;
>>
>> readf("%s", &i);
>> readf("%s", &j);
>>
>> When the input is
>>
>> 42 43
>>
>> the output is
>>
>> std.conv.ConvError: std.conv(1070): Can't convert value
>> `LockingTextReader(File(807637C), )' of type LockingTextReader to
type int
>> [...]
>>
>> Is that by design? Should the users strip the input themselves?
>
> It looks like a bug to me.
Opened
http://d.puremagic.com/issues/show_bug.cgi?id=4656
Thank you,
Ali
Re: Andrei's Google Talk
On 16.08.2010 22:36, lurker wrote: > > This is unbelievable douchebaggery. The default ddoc IS good enough for most > of us. There is simply no need for more complex tools. I think ddoc hits the > sweet spot here by providing semi-professional looking html documents. Like > someone said earlier, you can always spent a week worth of time creating a > better tool for document generation. > > Doxygen STILL doesn't support D. What does this tell? It tells that C++ is > crappy for software development. The millions of C++ users haven't been able > to write a docgen support for D. It's just not possible. OTOH a qualified > compiler veteran such as Walter wrote a better tool in less than a week, > blindfolded. What's the point of this post? I never wanted to replace ddoc in any way - the syntax is the best documentation syntax that I've seen, the WYSIWYG ideology is great and it's great that ddoc can output to different formats. If it sounded like I was flaming or something, I did not want to. (I agree, the last point about <,> is quite hypothetical) But there are little problems with ddoc - I mentioned a few, some more are already known and some of these might even exist in doxygen as well. (I don't know doxygen and I always thought it's generated documentation looks ugly. I only know the msdn / ndoc / qooxdoo.org api documentation which IMHO beat doxygen) Sure most of these issues are often not important. But if it's possible why not fix these? Why is spending one week (of my time) to enhance ddoc (and fix the known bugs, I want to provide a fix for the known problem with stray parenthesis in the next few days) a bad thing? BTW: what do you consider to be "default ddoc"? I agree that the phobos documentation is fine, but there is no default ".ddoc" file shipped with dmd and the documentation generated without a special .ddoc file is not that great. -- Johannes Pfau
Re: readf for the novice
Ali Ãehreli Wrote:
> Since cstream is deprecated and stdio.readf is finally available with
> 2.048, I started modifying my D book by replacing code like
>
> T var;
> din.readf(&var);
>
> with
>
> T var;
> readf("%s", &var);
>
>
> 1) I couldn't go far, because stdio.readf does not ignore whitespace and
> code like the following fail:
>
> int i;
> int j;
>
> readf("%s", &i);
> readf("%s", &j);
>
> When the input is
>
> 42 43
>
> the output is
>
> std.conv.ConvError: std.conv(1070): Can't convert value
> `LockingTextReader(File(807637C), )' of type LockingTextReader to type int
> [...]
>
> Is that by design? Should the users strip the input themselves?
It looks like a bug to me.
> 2) This is not a show stopper, but having to provide a format string for
> simple value input is unnecessary. It makes D less suitable for
> programming novices. (I see D very easy for novices in general,
> especially compared to C and C++.)
Since D has TypeInfo for variadic arguments, you're right that a format string
shouldn't often be necessary.
> 3) We need a simple way of reading values from stdin if only for the novice.
>
> Another solution is using string.strip and conv.parse:
>
> auto line = strip(stdin.readln());
> auto i = parse!int(line);
> auto d = parse!double(line);
>
> but that requires importing std.string and std.conv in addition to
> std.stdio. Also, with that, both of the values must be on the same line.
>
> A novice should be able to read as simple as
>
> auto d = read!double();
> auto i = read!int();
Seems like a good idea to me.
readf for the novice
Since cstream is deprecated and stdio.readf is finally available with
2.048, I started modifying my D book by replacing code like
T var;
din.readf(&var);
with
T var;
readf("%s", &var);
1) I couldn't go far, because stdio.readf does not ignore whitespace and
code like the following fail:
int i;
int j;
readf("%s", &i);
readf("%s", &j);
When the input is
42 43
the output is
std.conv.ConvError: std.conv(1070): Can't convert value
`LockingTextReader(File(807637C), )' of type LockingTextReader to type int
[...]
Is that by design? Should the users strip the input themselves?
2) This is not a show stopper, but having to provide a format string for
simple value input is unnecessary. It makes D less suitable for
programming novices. (I see D very easy for novices in general,
especially compared to C and C++.)
3) We need a simple way of reading values from stdin if only for the novice.
Another solution is using string.strip and conv.parse:
auto line = strip(stdin.readln());
auto i = parse!int(line);
auto d = parse!double(line);
but that requires importing std.string and std.conv in addition to
std.stdio. Also, with that, both of the values must be on the same line.
A novice should be able to read as simple as
auto d = read!double();
auto i = read!int();
Ignoring stripping whitespace, read can be implemented like this:
T read(T)()
{
T value;
readf("%s", &value);
return value;
}
Actually stream.readf's signature was also nice. Can we do the same with
stdio.readf?
readf(&v0, &v1, &v2);
Ali
Re: Andrei's Google Talk
Johannes Pfau Wrote:
> On 16.08.2010 04:53, Walter Bright wrote:
> > BCS wrote:
> >>> This seems excessive.
> >>>
> >> Unless you are setting up a new output format, you will never see
> >> them. In that light, it doesn't seem excessive to me.
> >
> > Adding features because one can isn't good enough. One should only add
> > features if they fill a real need.
> bla blah blah bla
{snip}
>
> --
> Johannes Pfau
This is unbelievable douchebaggery. The default ddoc IS good enough for most of
us. There is simply no need for more complex tools. I think ddoc hits the sweet
spot here by providing semi-professional looking html documents. Like someone
said earlier, you can always spent a week worth of time creating a better tool
for document generation.
Doxygen STILL doesn't support D. What does this tell? It tells that C++ is
crappy for software development. The millions of C++ users haven't been able to
write a docgen support for D. It's just not possible. OTOH a qualified compiler
veteran such as Walter wrote a better tool in less than a week, blindfolded.
Re: To avoid some 32=>64 bit user code port bugs
Isn't typedef being deprecated? Which brings us back to the task of augmenting the library-based alternative. I already started 2 threads about this.
Re: To avoid some 32=>64 bit user code port bugs
And some more: http://www.viva64.com/content/articles/64-bit-development/?f=64-bit-migration-7-steps.html&lang=en&content=64-bit-development http://www.viva64.com/content/articles/64-bit-development/?f=20_issues_of_porting_C++_code_on_the_64-bit_platform.html&lang=en&content=64-bit-development On Mon, Aug 16, 2010 at 10:23 PM, Andrej Mitrovic < andrej.mitrov...@gmail.com> wrote: > Here are some other articles about problems with 32bit>64bit porting if > anyone is interested: > > > http://www.viva64.com/content/articles/64-bit-development/?f=64-bit-arithmetic.html&lang=en&content=64-bit-development > > http://www.viva64.com/content/articles/64-bit-development/?f=TrapsDetection.html&lang=en&content=64-bit-development > > http://www.viva64.com/content/articles/64-bit-development/?f=size_t_and_ptrdiff_t.html&lang=en&content=64-bit-development > > > On Mon, Aug 16, 2010 at 10:19 PM, Yao G. wrote: > >> On Mon, 16 Aug 2010 09:40:15 -0500, bearophile >> wrote: >> >> This shows many pitfalls regarding conversion of 32 bit code to 64, some >>> of them are relevant for D code too: >>> http://www.gamedev.net/reference/articles/article2767.asp >>> >> >> Thanks for sharing this article bearophile. It's actually pretty good and >> comprehensive. >> >> >> -- >> Yao G. >> > >
Re: To avoid some 32=>64 bit user code port bugs
Here are some other articles about problems with 32bit>64bit porting if anyone is interested: http://www.viva64.com/content/articles/64-bit-development/?f=64-bit-arithmetic.html&lang=en&content=64-bit-development http://www.viva64.com/content/articles/64-bit-development/?f=TrapsDetection.html&lang=en&content=64-bit-development http://www.viva64.com/content/articles/64-bit-development/?f=size_t_and_ptrdiff_t.html&lang=en&content=64-bit-development On Mon, Aug 16, 2010 at 10:19 PM, Yao G. wrote: > On Mon, 16 Aug 2010 09:40:15 -0500, bearophile > wrote: > > This shows many pitfalls regarding conversion of 32 bit code to 64, some >> of them are relevant for D code too: >> http://www.gamedev.net/reference/articles/article2767.asp >> > > Thanks for sharing this article bearophile. It's actually pretty good and > comprehensive. > > > -- > Yao G. >
Re: To avoid some 32=>64 bit user code port bugs
On Mon, 16 Aug 2010 09:40:15 -0500, bearophile wrote: This shows many pitfalls regarding conversion of 32 bit code to 64, some of them are relevant for D code too: http://www.gamedev.net/reference/articles/article2767.asp Thanks for sharing this article bearophile. It's actually pretty good and comprehensive. -- Yao G.
Re: To avoid some 32=>64 bit user code port bugs
On Aug 16, 10 23:19, Trass3r wrote: So I think size_t=>uint may require a cast on 32 bit systems too, so when the code gets compiled with the 64 bit dmd this error isn't present. Well just make size_t a typedef instead of an alias. Isn't typedef being deprecated?
Re: Unit tests in libraries?
Mike Linford wrote: On Mon, 16 Aug 2010 10:26:46 -0700, Walter Bright wrote: Mike Linford wrote: The unit test does not get run when compiled as: dmd -lib mylib.d dmd main.d mylib.a But does get run when compiled as dmd main.d mylib.d You need to compile with -unittest to run them. Also, the following creates a library that does run the unit tests: dmd -c -unittest mylib.d ar -rc mylib.a mylib.o dmd -unittest main.d mylib.a Right, that's working as it should.
Re: Unit tests in libraries?
On Mon, 16 Aug 2010 10:26:46 -0700, Walter Bright wrote: > Mike Linford wrote: >> The unit test does not get run when compiled as: dmd -lib mylib.d >> dmd main.d mylib.a >> >> But does get run when compiled as >> dmd main.d mylib.d > > > You need to compile with -unittest to run them. Also, the following creates a library that does run the unit tests: dmd -c -unittest mylib.d ar -rc mylib.a mylib.o dmd -unittest main.d mylib.a -- Mike Linford
Re: Unit tests in libraries?
On Mon, 16 Aug 2010 10:26:46 -0700, Walter Bright wrote: > Mike Linford wrote: >> The unit test does not get run when compiled as: dmd -lib mylib.d >> dmd main.d mylib.a >> >> But does get run when compiled as >> dmd main.d mylib.d > > > You need to compile with -unittest to run them. Sorry, I forgot to include that I DID include -unittest in all compile lines. -- Mike Linford
Re: Andrei's Google Talk
Johannes Pfau wrote: [...] lots of stuff Some good arguments.
Re: Unit tests in libraries?
Mike Linford wrote: The unit test does not get run when compiled as: dmd -lib mylib.d dmd main.d mylib.a But does get run when compiled as dmd main.d mylib.d You need to compile with -unittest to run them.
Re: Precise garbage collection
Leandro Lucarella: > Unfortunately full preciseness is not possible in D, due to unions mostly. But unions are not so common in D code. > Having a precise stack would be very hard (and probably costly, > so not very suitable for D) LLVM contains tools to implement precise stack tracing. Once some application is available for D2, and once a LLVM-based D2 compiler exists, I think those tools can be used to perform experiments, to see how much costly they are, how much precision they give, etc (even if they are not present with DMD). > This above patch is applied in official version D ? With the current "speed" it may take two years :-) You probably have to wait. Bye, bearophile
Re: The Status of Const
Michel Fortin wrote: We're reinventing static-inheritance using "alias this". Static this has been from the get-go the intent to achieve subtyping for structs. I, too, think that a solution to tail const for ranges should gravitate around alias this. Andrei
Re: The Status of Const
On 2010-08-16 11:39:15 -0400, "Steven Schveighoffer"
said:
Translating it to your example, should you be able to convert from a
const(SmartPointer!X) to a SmartPointer!(const X) ? I'd say no,
because const(SmartPointer!X) guarantees that the refCount will not
change.
Indeed, you can't convert const(SmartPointer!X) to SmartPointer!(const
X). Doing that is what I'd call logical-const, and it'd be contrary to
the const system in D.
Implicit casting to your version of tail-const breaks that guarantee.
I only suggested casting the other way around: SmartPointer!(X) to
SmartPointer!(const X). You're implying things I didn't meant because
your definition of tail-const is different than mine.
One of the *essential* properties of tail const is you should always
be able to implicitly convert a const(T) to a tail const(T).
Then, by *your* definition of tail const, the SmartPointer cannot be
tail-const. *My* definition of tail-const just means that the tail is
const and the head is not, irrespective of what conversions are allowed.
So I think we agree except on the correct definition for tail-const. I
think mine is simpler and more to the point, but that's just my opinion.
Wouldn't defining ranges like the above fix the problem? And you could
make ranges cast implicitly to their "tail-const" form when needed,
exactly like the smart pointer above.
It might make it possible, but it would be a mess. A range would be a
templated type inside the templated container type. Or you could
define a range outside the container type to avoid odd issues.
The important things is to have the constness of the container "known"
by the range type, so all you need is two separate ranges types
(template arguments create separate types). The STL uses iterator and
const_iterator, that'd work too. Which brings me to...
But implicit casting is going to be difficult. You also have to
contend with stuff like this:
struct Range(V)
{
static if(isConst!(V)) // not sure if this exists, but assume it does
{
bool makeUncastable;
}
V *cur;
}
So a Range!(const(V)) cannot be implicitly converted to Range!V because
the layout is different. I'd rather not rely on templates and
compile-time decisions, and just let the compiler enforce the simple
cases.
For complicated cases like the one above, wouldn't a layout such as
this one work?
struct ConstRange(V) {
...
}
struct Range(V) {
ConstRange _constRange;
alias _constRange this;
...
}
We're reinventing static-inheritance using "alias this". :-) Of course,
I'm assuming implicit conversion from Range to ConstRange will work
somehow; this still need to be fixed.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: The Status of Const
On Mon, 16 Aug 2010 11:30:10 -0400, Michel Fortin
wrote:
On 2010-08-16 11:23:24 -0400, Michel Fortin
said:
Shouldn't this work?
struct Array(V) {
uint length;
V *v;
Array!(const V) _const() @property { ... }
alias _const this;
}
Well, it doesn't, but perhaps it should.
I agree that implicit conversions is the core of the problem for
tail-const in structs.
If the mechanism isn't automatic, and involves doing stuff like this, I
don't see it being used much. The compiler has to help here somewhere.
-Steve
Re: The Status of Const
On Mon, 16 Aug 2010 10:50:04 -0400, Michel Fortin
wrote:
On 2010-08-16 10:03:58 -0400, "Steven Schveighoffer"
said:
On Mon, 16 Aug 2010 09:26:55 -0400, Michel Fortin
wrote:
I think what you want for that is to somehow make SmartPtr!(X)
implicitly derived from SmartPtr!(const X), you don't want the
compiler applying blindly tail-const to all the members.
Again, it's logical const, no matter how you slice it.
If you see it that way, then D const is logical const too.
Logical const fits within the realm of const. I've proven in the past
that logical const can be emulated without modification to the type
system. But applying tail const is not applying logical const. If you
want to apply a different type of const to a type, then that is not const
or tail-const. It's not invalid or unsafe, but it's another type of const
besides tail const and normal const.
I'm not proposing we create a mutable island inside a const struct or
class (thus not breaking the transitivity), so it does abide by D
current definition of const. Here's some definition?
struct SmartPointer(T) {
T* pointer;
uint* refCount;
}
SmartPointer!(const X) pointer;
All I am saying is that the "conceptual" tail-const form of
SmartPointer!(X) is SmartPointer!(const X), and that it'd be useful that
SmartPointer!(X) and SmartPointer!(immutable X) could implicitly cast to
SmartPointer!(const X).
Likewise, you could say the const version of SmartPointer only applies
const to the pointer part, because refcount is not part of its state. It
was the basis for my argument for including a way to do logical const in
the past. It's logical const, or rather, logical tail-const :)
That might be "logical const" to you as long as you think "tail const"
for struct is "all members become tail const", but I think that
definition of tail-const is pointless and that there should not be any
real tail-const for structs except the one you can induce through its
template arguments.
Is implicitly converting from const(int[]) to const(int)[] useless? If
you think that, then I agree that we disagree.
When making a tail-const copy of a const struct, you should be able to
simply remove the const decorations of the values you are copying, but not
the data it references. That violates the guarantee of const.
Translating it to your example, should you be able to convert from a
const(SmartPointer!X) to a SmartPointer!(const X) ? I'd say no, because
const(SmartPointer!X) guarantees that the refCount will not change.
Implicit casting to your version of tail-const breaks that guarantee. One
of the *essential* properties of tail const is you should always be able
to implicitly convert a const(T) to a tail const(T).
As for constness of ranges, it's quite similar. The thing is that you
generally have three possible levels of constness. The range might be
const, the container the range points to might be const, and the
elements in the container might be const. If ranges were expressed like
this:
struct Range(ContainerType) {...}
then it'd be easy to say whether the container and the element type is
const or not just like this:
Range!(Container!(const Element))
Range!(const Container!(immutable Element))
Range!(immutable Container!(immutable Element))
A range on a container is typically already parameterized on the
container, because it's usually a subtype of the container. But I think
that in order for container ranges to do the right thing, containers of
const elements should return tail const ranges of non-const elements.
Otherwise, implicit conversion would be impossible.
So given a container parameterized with Element, and a function:
R opSlice() const {...}
The R type should be @tail const(Container!Element.range), even on a
Container!(const(Element)).
Most ranges are not defined like this: the type of the containeris
implied in the type of the range, but the constness of the container is
simply missing.
Yes, that is one of the reasons I have avoided doing const ranges on
dcollections, all ranges use the container's parameters for the element
type.
Wouldn't defining ranges like the above fix the problem? And you could
make ranges cast implicitly to their "tail-const" form when needed,
exactly like the smart pointer above.
It might make it possible, but it would be a mess. A range would be a
templated type inside the templated container type. Or you could define a
range outside the container type to avoid odd issues. But implicit
casting is going to be difficult. You also have to contend with stuff
like this:
struct Range(V)
{
static if(isConst!(V)) // not sure if this exists, but assume it does
{
bool makeUncastable;
}
V *cur;
}
So a Range!(const(V)) cannot be implicitly converted to Range!V because
the layo
Re: The Status of Const
On 2010-08-16 11:23:24 -0400, Michel Fortin said:
Shouldn't this work?
struct Array(V) {
uint length;
V *v;
Array!(const V) _const() @property { ... }
alias _const this;
}
Well, it doesn't, but perhaps it should.
I agree that implicit conversions is the core of the problem for
tail-const in structs.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: The Status of Const
On 2010-08-16 11:17:32 -0400, "Steven Schveighoffer"
said:
struct Array(V)
{
uint length;
V *v;
}
How can we turn Array!V into Array!(const(V)) implicitly...
Shouldn't this work?
struct Array(V) {
uint length;
V *v;
Array!(const V) _const() @property { ... }
alias _const this;
}
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: To avoid some 32=>64 bit user code port bugs
So I think size_t=>uint may require a cast on 32 bit systems too, so when the code gets compiled with the 64 bit dmd this error isn't present. Well just make size_t a typedef instead of an alias.
Re: The Status of Const
On Mon, 16 Aug 2010 10:58:52 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
Hopefully, Andrei will eventually get around to dealing with const in
std.container and see what a mess it will become without some sort of
tail-const for ranges.
I believe at some point an approach will come forth. Here are a few
quick thoughts on this large exchange:
* I think head-const has its usefulness, and tail-const is obviously in
need for serious attention. Ideally we should reach, with no or minimal
language changes, the point at which full const is the built-in power
tool and head-const and tail-const are library artifacts. I think it's
quite easy to define a Final!T template that is head-const, and
Rebindable!T is a starting point for tail-const classes. We need to
figure a pattern for achieving tail constness for general types.
Tail-const is already not a library solution. A tail const pointer or
array is possible without library support.
If a solution can be had via a library, it must still enjoy some compiler
support for implicit casting. It must also avoid any undue extra code
generation. Const is purely a compile-time feature, it plays no role in
the eventual generated code. It simply prevents cases which the developer
has asked it to prevent.
* Const and immutable will be used less often than in C++. This might
seem a weakness to those coming from C++ where const can and should be
sprinkled often, but it is a natural consequence of the relative
restrictions imposed by const in C++ vs. D. D's const is more
restrictive, and as such will find its way in fewer idioms than C++'s.
Currently, object is very const incorrect. Once it becomes const-correct,
I think this observation may drastically change. But more importantly,
many pieces of phobos/druntime simply don't work with const (dup/idup
comes to mind). It may not be a case that const isn't required, but more
that const can't be correctly implemented without incurring lots of code
duplication. So we all "put off" making things const correct until const
is fixed. Observing that D currently isn't full of tail-const references
may be an artifact of that problem.
* Perhaps a good starting point is to look at std.container.SList and
see how const(SList!T) can be manipulated.
We can start simpler than that. Give a struct:
struct Array(V)
{
uint length;
V *v;
}
How can we turn Array!V into Array!(const(V)) implicitly...
This will duplicate array tail-const, and be essential to making
tail-const ranges.
It should be a good starting test for any library/compiler solution.
-Steve
Re: Precise garbage collection
Borneq, el 16 de agosto a las 07:53 me escribiste: > Conservative garbage collection causes memory leaks. In D is added: > http://d.puremagic.com/issues/show_bug.cgi?id=3463 > This is semi precise - only the heap have type information. What > type information has fully precise? Semi precise causes memory > leaks? Unfortunately full preciseness is not possible in D, due to unions mostly. Having a precise stack would be very hard (and probably costly, so not very suitable for D) but having a precise static data (and a more accurate one) maybe is possible, see bug 4650: http://d.puremagic.com/issues/show_bug.cgi?id=4650 Memory leaks will always be possible in D, but I think if the stack is the only part that should be scanned in conservative mode, they can greatly be reduced. > This above patch is applied in official version D ? Not yet, vote up! =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Demasiado lento para una estrella fugaz Demasiado limpio para lo que vos acostumbras Demasiado claro para tanta oscuridad Demasiados sueños, poca realidad
Re: The Status of Const
On Mon, 16 Aug 2010 11:00:21 -0400, Andrei Alexandrescu wrote: Steven Schveighoffer wrote: On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu wrote: On 08/13/2010 06:35 PM, Walter Bright wrote: Steven Schveighoffer wrote: I like how it reads naturally. I think it's also syntactically unambiguous. Walter, please give this one some attention, I'd love to see this fixed. This was endlessly discussed maybe 3 years ago. I probably invested over a hundred hours in trying to make it work. It doesn't work. Perhaps part of this is the reluctance to reexamine something which was hard to prove correct given the ideas at the time? However, the idea is attainable. For the simple fact that we have tail-const references in other parts of the language. All that is missing is syntax. [snip] This seems to be a misquote. You are replying to Walter, not me. I was replying to both your points and Walter's. Walter's name is quoted just below yours. -Steve
Re: The Status of Const
Steven Schveighoffer wrote: On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu wrote: On 08/13/2010 06:35 PM, Walter Bright wrote: Steven Schveighoffer wrote: I like how it reads naturally. I think it's also syntactically unambiguous. Walter, please give this one some attention, I'd love to see this fixed. This was endlessly discussed maybe 3 years ago. I probably invested over a hundred hours in trying to make it work. It doesn't work. Perhaps part of this is the reluctance to reexamine something which was hard to prove correct given the ideas at the time? However, the idea is attainable. For the simple fact that we have tail-const references in other parts of the language. All that is missing is syntax. [snip] This seems to be a misquote. You are replying to Walter, not me. Andrei
Re: private vs protected in Interfaces
Andrei Alexandrescu wrote: On 08/15/2010 04:01 AM, Ali Çehreli wrote: Jonathan M Davis wrote: It would not be good to be unable to do NVI. I am not saying that it should not be supported; but... I've used NVI a number of times myself until I was convinced by Kevlin Henney that it was "a solution in search of a problem" during one of his many excellent presentations at the Silicon Valley ACCU: http://www.accu-usa.org/Slides/ACriticalViewOfCppPractices.pdf Interesting. I think Kevlin is an outstanding designer, and I agree with him that applying NVI as a convention in languages that have little support for it is tenouos. I disagree with a few points his slides make, and am informing him of this discussion to allow him to chime in if he wants. [snip] Just got word from Kevlin that he's on vacation with family, so he won't reply to this anytime soon. Andrei
Re: The Status of Const
Steven Schveighoffer wrote: Hopefully, Andrei will eventually get around to dealing with const in std.container and see what a mess it will become without some sort of tail-const for ranges. I believe at some point an approach will come forth. Here are a few quick thoughts on this large exchange: * The discussion this time around reflects a deep and thorough understanding of the issues involved throughout the community. * I think head-const has its usefulness, and tail-const is obviously in need for serious attention. Ideally we should reach, with no or minimal language changes, the point at which full const is the built-in power tool and head-const and tail-const are library artifacts. I think it's quite easy to define a Final!T template that is head-const, and Rebindable!T is a starting point for tail-const classes. We need to figure a pattern for achieving tail constness for general types. * Const and immutable will be used less often than in C++. This might seem a weakness to those coming from C++ where const can and should be sprinkled often, but it is a natural consequence of the relative restrictions imposed by const in C++ vs. D. D's const is more restrictive, and as such will find its way in fewer idioms than C++'s. * Perhaps a good starting point is to look at std.container.SList and see how const(SList!T) can be manipulated. Andrei
Re: To avoid some 32=>64 bit user code port bugs
On 8/16/10, bearophile wrote: > So I think size_t=>uint may require a cast on 32 > bit systems too, so when the code gets compiled with the 64 bit dmd this > error isn't present. I don't think that's a good idea because of what you say later in your post: the cast punches a hole through the system. On 32 bit, the cast is certainly safe, but on 64 bit, it might not be, but the compiler won't complain. I think right now, size_t is an alias to uint. On 64 bit, it'll probably be an alias to ulong. That means assigning to uint won't compile, so it draws your attention to the line. You can look it over and decide if the cast is actually warranted or not. If you put the cast there in 32 bit, it will work and might silently break it later in 64 bit. Casts should be avoided whenever possible. Every required cast is another potential silent bug down the line. > So 64 bit DMD may show a warning for pointer=>uint casts, I don't know. That's probably a good idea.
Re: The Status of Const
On 2010-08-16 10:03:58 -0400, "Steven Schveighoffer"
said:
On Mon, 16 Aug 2010 09:26:55 -0400, Michel Fortin
wrote:
I think what you want for that is to somehow make SmartPtr!(X)
implicitly derived from SmartPtr!(const X), you don't want the compiler
applying blindly tail-const to all the members.
Again, it's logical const, no matter how you slice it.
If you see it that way, then D const is logical const too. I'm not
proposing we create a mutable island inside a const struct or class
(thus not breaking the transitivity), so it does abide by D current
definition of const. Here's some definition?
struct SmartPointer(T) {
T* pointer;
uint* refCount;
}
SmartPointer!(const X) pointer;
All I am saying is that the "conceptual" tail-const form of
SmartPointer!(X) is SmartPointer!(const X), and that it'd be useful
that SmartPointer!(X) and SmartPointer!(immutable X) could implicitly
cast to SmartPointer!(const X). That might be "logical const" to you as
long as you think "tail const" for struct is "all members become tail
const", but I think that definition of tail-const is pointless and that
there should not be any real tail-const for structs except the one you
can induce through its template arguments.
As for constness of ranges, it's quite similar. The thing is that you
generally have three possible levels of constness. The range might be
const, the container the range points to might be const, and the
elements in the container might be const. If ranges were expressed like
this:
struct Range(ContainerType) {...}
then it'd be easy to say whether the container and the element type is
const or not just like this:
Range!(Container!(const Element))
Range!(const Container!(immutable Element))
Range!(immutable Container!(immutable Element))
Most ranges are not defined like this: the type of the containeris
implied in the type of the range, but the constness of the container is
simply missing. Wouldn't defining ranges like the above fix the
problem? And you could make ranges cast implicitly to their
"tail-const" form when needed, exactly like the smart pointer above.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
To avoid some 32=>64 bit user code port bugs
This shows many pitfalls regarding conversion of 32 bit code to 64, some of
them are relevant for D code too:
http://www.gamedev.net/reference/articles/article2767.asp
On 32 bit D systems this compiles with no errors, while on 64 bit D this
probably requires a cast:
size_t foo() { return -1; }
void main() {
uint r = foo();
}
I'd like D to be designed to make 32=>64 porting as bug-free as possible, so
dmd may guard against some possible 64bit troubles even if the code is compiled
in 32 bit mode. So I think size_t=>uint may require a cast on 32 bit systems
too, so when the code gets compiled with the 64 bit dmd this error isn't
present.
---
With the 32 bit DMD this code works:
void main() {
int x;
int* ptr = &x;
uint y = cast(uint)ptr;
// ... usage of y
}
The cast() silences the compiler on 64 bit systems too, but on 64 bit systems
this may be more correct:
size_t value = cast(size_t)ptr;
A cast() is a way for the programmer to express the desire to punch a hole in
the type system, but in my opinion not all casts are equally unsafe. Some of
them are _more_ bug-prone than others. On 64 bit systems a pointer=>uint cast
is less safe than a pointer=>size_t cast or a pointer=>ptrdiff_t cast, because
it's a lossless transformation.
(In practice I think that a pointer=>uint is a bad thing even in 32 bit code,
when a sign is really necessary it's probably better to use ptrdiff_t on 32 bit
systems too).
So 64 bit DMD may show a warning for pointer=>uint casts, I don't know.
Bye,
bearophile
Re: The Status of Const
On Mon, 16 Aug 2010 09:11:20 -0400, dsimcha wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
There are other reasons to have tail-const other than classes. For
example, there's no equivalent custom-range idiom for const(T)[]. You
simply can't make a custom range tail-const.
I admit I haven't used Rebindable much, but last I checked it was
severely
out of date.
-Steve
Rebindable's gotten a significant facelift lately. Admittedly there are
still
bugs but these are bugs in alias this/opDot, not in rebindable itself.
How do you tail-const a range?
struct Node(V)
{
V v;
Node * next;
}
struct Range(V)
{
Node!V *n;
void popFront() {n = n.next};
}
How does one implement popFront so it works on:
Rebindable!(const(Range!V)) r;
???
Rebindable is specifically for class references, it does nothing for
ranges.
-Steve
Re: The Status of Const
On Mon, 16 Aug 2010 09:26:55 -0400, Michel Fortin wrote: On 2010-08-16 09:08:30 -0400, "Steven Schveighoffer" said: On Mon, 16 Aug 2010 08:56:51 -0400, Michel Fortin wrote: The idea's not bad, but I think it needs some improvments. For instance, in a struct, I might want some members to be part of the tail and some other not. I believe that should be allowed somehow. What do you mean "not", meaning they are fully const? Because you can't not apply const to references inside a const struct, that's logical const, and while it might be a nice feature, Walter has steadfastly refused to allow it. I'm not arguing for logical const. Logical const means that you have an island of non-const inside a const structure. That's not what I meant. When you want your struct to be tail-const, what it means is that you want the members inside it to be tail-const. The structure itself is not const, just the members, an just the tail of the members. But do you always want *all* the members to be tail const? Yes. Not doing this violates the promise of const. This is exactly the same as logical const, even though the storage is not with the object itself. It's ok to do it to the head members because the head part is always copied by value. Say your struct is a reference counting smart pointer that works by having two pointers: one points to the actual object, the other points to the reference counter (boost::shared_ptr's design). This smart pointer basically has two tails, one for each internal pointer. But if you apply "tail const" to the smart pointer, you probably only want the pointer to the actual object to be tail-const. That's because making the pointer to the reference counter tail-const would just prevent you from updating the counter, which in turn would prevent you from assigning something different to the smart pointer. That's logical const. I'm not saying it's not useful, but tail-const is not logical const. A property of tail const that logical const does not share is that all referenced data in a const item is also constant in a tail-const reference. The same is not true with logical const. FWIW, I had proposed a complex system to Walter/Andrei that allowed for applying any kind of constancy to an object, and have the compiler deal with proper implicit casts. However, the system is very complex, with people able to arbitrarily name const *flavors*. It wouldn't have been very usable... I think a possible solution is possibly to create a mutable library type that always stays mutable in const and immutable flavors of an object. Such a wrapper type should take into account the undefined aspects of doing such a thing. I think what you want for that is to somehow make SmartPtr!(X) implicitly derived from SmartPtr!(const X), you don't want the compiler applying blindly tail-const to all the members. Again, it's logical const, no matter how you slice it. -Steve
Re: The Status of Const
On 2010-08-16 09:08:30 -0400, "Steven Schveighoffer" said: On Mon, 16 Aug 2010 08:56:51 -0400, Michel Fortin wrote: The idea's not bad, but I think it needs some improvments. For instance, in a struct, I might want some members to be part of the tail and some other not. I believe that should be allowed somehow. What do you mean "not", meaning they are fully const? Because you can't not apply const to references inside a const struct, that's logical const, and while it might be a nice feature, Walter has steadfastly refused to allow it. I'm not arguing for logical const. Logical const means that you have an island of non-const inside a const structure. That's not what I meant. When you want your struct to be tail-const, what it means is that you want the members inside it to be tail-const. The structure itself is not const, just the members, an just the tail of the members. But do you always want *all* the members to be tail const? Say your struct is a reference counting smart pointer that works by having two pointers: one points to the actual object, the other points to the reference counter (boost::shared_ptr's design). This smart pointer basically has two tails, one for each internal pointer. But if you apply "tail const" to the smart pointer, you probably only want the pointer to the actual object to be tail-const. That's because making the pointer to the reference counter tail-const would just prevent you from updating the counter, which in turn would prevent you from assigning something different to the smart pointer. I think what you want for that is to somehow make SmartPtr!(X) implicitly derived from SmartPtr!(const X), you don't want the compiler applying blindly tail-const to all the members. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: The Status of Const
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > On Fri, 13 Aug 2010 19:30:46 -0400, dsimcha wrote: > > == Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article > >> On Friday, August 13, 2010 15:03:07 Tomek Sowiński wrote: > >> > I agree with the content, but not the tone. D's const makes all other > >> > mainstream const systems look petty. Applying the concept of > >> transitivity > >> > has been revolutionary (hail Walter). Tail const is just a cable to > >> the > >> > socket to make this wonderful device work out-of-box for programming > >> > masses. > >> In pretty much all cases other than references, D's const system is > >> fantast > >> ic. > >> It really simplified things in comparison to C++, and is overall a > >> definite > >> > >> improvement. It's just with references that there's a big problem, and > >> with > >> > >> them, they're better than what you get with Java's final, but it's still > >> seriously lacking due to the whole thing becoming const instead of just > >> the > >> > >> referent. > >> - Jonathan M Davis > > > > I still don't understand: What's so bad about Rebindable? Yes, it's > > not the > > syntactically prettiest thing in the world, but complaining about it is > > like > > complaining about climbing a molehill when you've got Mount Everest to > > climb next. > > My previous gripe about it was that it didn't support interfaces, but I > > just > > realized that Shin Fujishiro fixed this a while back. > There are other reasons to have tail-const other than classes. For > example, there's no equivalent custom-range idiom for const(T)[]. You > simply can't make a custom range tail-const. > I admit I haven't used Rebindable much, but last I checked it was severely > out of date. > -Steve Rebindable's gotten a significant facelift lately. Admittedly there are still bugs but these are bugs in alias this/opDot, not in rebindable itself.
Re: The Status of Const
On Mon, 16 Aug 2010 08:56:51 -0400, Michel Fortin wrote: On 2010-08-16 08:08:21 -0400, "Steven Schveighoffer" said: On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu wrote: On 08/13/2010 06:35 PM, Walter Bright wrote: Steven Schveighoffer wrote: I like how it reads naturally. I think it's also syntactically unambiguous. Walter, please give this one some attention, I'd love to see this fixed. This was endlessly discussed maybe 3 years ago. I probably invested over a hundred hours in trying to make it work. It doesn't work. Perhaps part of this is the reluctance to reexamine something which was hard to prove correct given the ideas at the time? However, the idea is attainable. For the simple fact that we have tail-const references in other parts of the language. All that is missing is syntax. It wasn't the syntax. There were many syntaxes proposed. The type system loses its coherency with such a special case in it. Generic code has weird problems, type deduction gets strange, types lose their composability, etc. The fact that all syntaxes proposed back then didn't cut the mustard does not mean that no possible syntax exists. This is not NP != P. Given that we have syntax that works for pointers, it's logical and reasonable to assume that some syntax can work for generic tail-constness of everything. In fact, we had syntax that *worked* it was just confusing. Indeed. This reflects my opinion too. I'm not saying much about this issue right now because I feel it's no use, or to be precise, so much time convincing is needed to bring something useful I'd rather do something else. I've taken the route where I'll wait until others (Andrei?) hit the same problems and put enough pressure to force the design to be revisited. Hopefully this will happen sooner rather than later. Yeah, it's why I let it go before. But I think in light of the new ability to use attributes, and the need for it in my own project (dcollections), I want to try and push it again. I may even try my hand at compiler hacking... Hopefully, Andrei will eventually get around to dealing with const in std.container and see what a mess it will become without some sort of tail-const for ranges. Same situation for @safe, same for pure, same for shared. Which means I won't be adopting D2's most interesting features for some time. BTW, I like Tomek's idea with @tail const/immutable/shared. It's not a special case, it's a generic case, you can apply it to any type. The idea's not bad, but I think it needs some improvments. For instance, in a struct, I might want some members to be part of the tail and some other not. I believe that should be allowed somehow. What do you mean "not", meaning they are fully const? Because you can't not apply const to references inside a const struct, that's logical const, and while it might be a nice feature, Walter has steadfastly refused to allow it. If you do mean fully const, then I'm not sure why you'd want that. -Steve
Re: Phobos urllib
13.08.2010 22:27, Nick Sabalausky wrote: "Adam Ruppe" wrote in message news:mailman.284.1281721417.13841.digitalmar...@puremagic.com... On 8/13/10, Graham Fawcett wrote: Just FYI, if you add 'pragma(lib, "curl");' to the top of your curl.d file, you shouldn't need '-L-lcurl' any more; dmd will add it automatically during linking. Very cool. For some reason, I thought that didn't work on linux... I must have just been doing it wrong before. I had been thinking it was just a feature of "bud". Very good to know. It works well with .d files, but not with import (.di) files. Both on Windows and Linux. Maybe I miss something? --
Re: The Status of Const
On 2010-08-16 08:08:21 -0400, "Steven Schveighoffer" said: On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu wrote: On 08/13/2010 06:35 PM, Walter Bright wrote: Steven Schveighoffer wrote: I like how it reads naturally. I think it's also syntactically unambiguous. Walter, please give this one some attention, I'd love to see this fixed. This was endlessly discussed maybe 3 years ago. I probably invested over a hundred hours in trying to make it work. It doesn't work. Perhaps part of this is the reluctance to reexamine something which was hard to prove correct given the ideas at the time? However, the idea is attainable. For the simple fact that we have tail-const references in other parts of the language. All that is missing is syntax. It wasn't the syntax. There were many syntaxes proposed. The type system loses its coherency with such a special case in it. Generic code has weird problems, type deduction gets strange, types lose their composability, etc. The fact that all syntaxes proposed back then didn't cut the mustard does not mean that no possible syntax exists. This is not NP != P. Given that we have syntax that works for pointers, it's logical and reasonable to assume that some syntax can work for generic tail-constness of everything. In fact, we had syntax that *worked* it was just confusing. Indeed. This reflects my opinion too. I'm not saying much about this issue right now because I feel it's no use, or to be precise, so much time convincing is needed to bring something useful I'd rather do something else. I've taken the route where I'll wait until others (Andrei?) hit the same problems and put enough pressure to force the design to be revisited. Hopefully this will happen sooner rather than later. Same situation for @safe, same for pure, same for shared. Which means I won't be adopting D2's most interesting features for some time. BTW, I like Tomek's idea with @tail const/immutable/shared. It's not a special case, it's a generic case, you can apply it to any type. The idea's not bad, but I think it needs some improvments. For instance, in a struct, I might want some members to be part of the tail and some other not. I believe that should be allowed somehow. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: The Status of Const
On Mon, 16 Aug 2010 01:39:21 -0400, Kagamin wrote: Steven Schveighoffer Wrote: Syntactical. There is no way to separate the reference from the data, since the reference is a hidden artifact of the type system. Do you assert that there's only one possible syntax to express the type system? Not sure what you mean... -Steve
Re: The Status of Const
On Fri, 13 Aug 2010 19:30:46 -0400, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article On Friday, August 13, 2010 15:03:07 Tomek Sowiński wrote: > I agree with the content, but not the tone. D's const makes all other > mainstream const systems look petty. Applying the concept of transitivity > has been revolutionary (hail Walter). Tail const is just a cable to the > socket to make this wonderful device work out-of-box for programming > masses. In pretty much all cases other than references, D's const system is fantast ic. It really simplified things in comparison to C++, and is overall a definite improvement. It's just with references that there's a big problem, and with them, they're better than what you get with Java's final, but it's still seriously lacking due to the whole thing becoming const instead of just the referent. - Jonathan M Davis I still don't understand: What's so bad about Rebindable? Yes, it's not the syntactically prettiest thing in the world, but complaining about it is like complaining about climbing a molehill when you've got Mount Everest to climb next. My previous gripe about it was that it didn't support interfaces, but I just realized that Shin Fujishiro fixed this a while back. There are other reasons to have tail-const other than classes. For example, there's no equivalent custom-range idiom for const(T)[]. You simply can't make a custom range tail-const. I admit I haven't used Rebindable much, but last I checked it was severely out of date. -Steve
Re: The Status of Const
On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu wrote: On 08/13/2010 06:35 PM, Walter Bright wrote: Steven Schveighoffer wrote: I like how it reads naturally. I think it's also syntactically unambiguous. Walter, please give this one some attention, I'd love to see this fixed. This was endlessly discussed maybe 3 years ago. I probably invested over a hundred hours in trying to make it work. It doesn't work. Perhaps part of this is the reluctance to reexamine something which was hard to prove correct given the ideas at the time? However, the idea is attainable. For the simple fact that we have tail-const references in other parts of the language. All that is missing is syntax. It wasn't the syntax. There were many syntaxes proposed. The type system loses its coherency with such a special case in it. Generic code has weird problems, type deduction gets strange, types lose their composability, etc. The fact that all syntaxes proposed back then didn't cut the mustard does not mean that no possible syntax exists. This is not NP != P. Given that we have syntax that works for pointers, it's logical and reasonable to assume that some syntax can work for generic tail-constness of everything. In fact, we had syntax that *worked* it was just confusing. BTW, I like Tomek's idea with @tail const/immutable/shared. It's not a special case, it's a generic case, you can apply it to any type. But there is a solution: const(Object)* o; Yes, under the hood it's 2 levels of indirection. But it works, it requires no special syntax, it is completely consistent with the rest of how the type system works, there are no corner holes in it, etc. It obviously doesn't work. We wouldn't be discussing it if the group of people bringing fresh proposals who haven't seen the previous discussions weren't having issues with it. The rest of us who were involved with the discussions are cynical not because the problem can't be solved, but that you have stated that no solution exists and you aren't willing to look at it any more. The main problem with this hack is that the standard way to refer to a mutable class is with just a class reference. That doesn't implicitly cast to a tail-const class reference pointer. So anything that uses tail-const class references has to be specially constructed instead of just passing it. You can't just pass &x because x is a stack variable, which could be escaped. So you have to create a class reference on the heap, and then pass the address to it. Just try creating a class reference on the heap. In essence, you lose all the benefits of classes by making them tail-const with this method. The pain of dealing with tail-const class references via pointers makes you just not use them, because they are so awkward and cumbersome, especially when you see how elegantly D deals with tail const in the rest of the language. Actually this is an even better solution: const(Scoped!Type)* o; Wait, isn't this a pointer to data allocated on the stack? I must be misunderstanding something... The only issue is that you need to know the static type... polymorphism doesn't work with pointers. Yeah, for classes, this is a big big problem. For all those dmd hackers out there, I think we are stuck unless someone can create a dmd patch to show it can be done. Without that, I think Walter is simply unwilling to look at any possible solutions, having spent so much time trying to make it work. If we take his time/effort requirement out of the equation, it could be possible to get something through. I might take up dmd hacking just to get this working. -Steve
Re: D examples
On Mon, 16 Aug 2010 07:48:11 +0200, Borneq wrote: > Użytkownik "Leandro Lucarella" napisał w wiadomości > news:20100815212755.gd5...@llucax.com.ar... >> LDC doesn't use LLVM infrastructure for garbage collection. > > Garbage Collector is in Tango library? Yes, it's in the runtime part of the Tango library.
Re: Andrei's Google Talk
On 16.08.2010 04:53, Walter Bright wrote: > BCS wrote: One major aspect in my changes is that there should be no hardcoded output: everything can be redefined through macros, though sane defaults should be provided. Example: DDOC_DECLARATION_SEMICOLON=; DDOC_FUNCTION_VARARGS=...; DDOC_FUNCTION_COMMA=,; >>> This seems excessive. >>> >> >> Unless you are setting up a new output format, you will never see >> them. In that light, it doesn't seem excessive to me. > > Adding features because one can isn't good enough. One should only add > features if they fill a real need. I don't see a point to things like a > macro for a ;. The macro for the ; is needed because you might want to strip it out in the final output. With hardcoded ; this is not easily doable. If you look at the posted examples you will see that I hide the ; for most types. This is the only way to achieve something like ; which now allows all kinds of css stuff. The xml output for example completely ignores semicolons and commas, because they don't make sense there. void testFunction int i ... Also consider that all macros have sane defaults. No one is required to redefine them if it's not needed. In fact most macros default to a simple $0 and unless you redefine these you'll never come across them. I agree though that there are lots of macros, maybe too many. But it's hard to find the point between too few and too many. This remembers me, that there is another limitation with the macro system. Consider for example: DDOC_CLASS DDOC_PROTECTION DDOC_FUNTION DDOC_PROTECTION In the DDOC_PROTECTION macro you never know whether this is the protection for the function or for the class. If you need different output for DDOC_PROTECTION depending on that, you'll have to define DDOC_CLASS_PROTECTION and DDOC_FUNCTION_PROTECTION or you have to generate xml first private and process this xml further, because with xml you can extract the parent elements. I know this is by design, and it's not a huge problem. But it means you need even more macros if you want to make rich output possible without a custom post processor. I know that the phobos problem is not directly a problem of ddoc. I just mentioned it because it also makes generating documentation for other formats harder. These phobos macros should maybe be moved to the std.ddoc file. But then we have custom phobos macros which must be redefined for generating a different output format and if every project defines there own macros like that, making .ddoc files to output to different formats soon becomes a mess. I agree that macros to output tables etc are needed though. But it's important that not every project defines it's own table macros. And one more problem, though not directly related to the macro system: If one really documented code in a WYSIWYG way and would not think he might be generating html, he could use <,> and &. This would definitely break html, which means you must make assumptions about the final output format in the documentation or you might break it. -- Johannes Pfau
Unit tests in libraries?
Sorry for the repost, but its been more than 24 hours in
digitalmars.D.learn
Is this a bug? Unit tests do not seem to work in libraries. I'm using dmd
1.062 for linux.
mylib.d :
module mylib;
void blah()
{
}
unittest
{
assert(false);
}
main.d :
module main;
import mylib;
void main()
{
blah();
}
The unit test does not get run when compiled as:
dmd -lib mylib.d
dmd main.d mylib.a
But does get run when compiled as
dmd main.d mylib.d
Is this the intended behavior for unit tests in libraries?
--
Mike Linford
