Re: Bug fix week
On 26/05/2010 21:14, Masahiro Nakagawa wrote: On Sun, 23 May 2010 22:50:14 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: We've had a tremendous infusion of talent and energy in Phobos, and lately work has picked up in unprecedented ways, both in terms of new features and bug fixes. I can't say how happy I am about that! At the end of this starting week, on Friday May 28, TDPL will be out on trucks to bookstores. Let's make this week a bug fixing week for both dmd and Phobos, and issue a release on Monday. We're going public! Andrei I think we need improvement of DDoc. Current DDoc doesn't keep up with D Spec(e.g. ignore @attribute, pure, etc...). I very much agree with this. -- Bruno Medeiros - Software Engineer
Re: dcollections 1.0 and 2.0a beta released
On 2010-05-27 12:32, Steven Schveighoffer wrote: On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 24/05/2010 16:45, Andrei Alexandrescu wrote: In the past I have built a C++ library that abstracted features of the OS. My goal was to make it possible to dynamically load a module that abstracted things like setting the IP address of a network interface. My modules used std::string instead of char * to lookup services to get objects that implement the interface. Big mistake. On a later version of the standard C++ runtime, the private implementation of std::string changed, so the dynamically loaded libraries crashed horribly. No change in string's interface, just the private stuff changed, but because it's a template, the code that uses it necessarily has to be aware of it. We ended up ditching the standard C++ library's version of string, and used STLPort so we could control the library. I envision this same sort of problem would be likely with D collection objects that were not used via interfaces. I see no problem retrofitting a no-interface container into a formal interface if so needed. I don't understand this discussion: isn't the reason above pretty much a dead-on hard requirement for the collections to have interfaces? Something like, for example, an interface version of the range traits? Only if you wish to have binary compatibility with dynamic libs. Such a thing isn't likely today since dynamic libs aren't very well supported in D, and even phobos or dcollections isn't a dynamic lib. I've got my patch, for build Tango as a dynamic library on Mac, quite recently included in trunk. And I've also have a patch for druntime and Phobos in bugzilla just waiting to be included + one patch making it easier creating dynamic libraries directly with DMD. I would say it's a bad idea to still think that dynamic libraries aren't support, we have to think forward and assume they will be supported. And I have specifically decided not to use interfaces with ranges because that makes them reference types. Ranges work well as value types, but not well as reference types. Therefore, to use dcollections as interfaces, you must not require the range traits. -Steve -- /Jacob Carlborg
Re: dcollections 1.0 and 2.0a beta released
On 27/05/2010 11:32, Steven Schveighoffer wrote: On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 24/05/2010 16:45, Andrei Alexandrescu wrote: In the past I have built a C++ library that abstracted features of the OS. My goal was to make it possible to dynamically load a module that abstracted things like setting the IP address of a network interface. My modules used std::string instead of char * to lookup services to get objects that implement the interface. Big mistake. On a later version of the standard C++ runtime, the private implementation of std::string changed, so the dynamically loaded libraries crashed horribly. No change in string's interface, just the private stuff changed, but because it's a template, the code that uses it necessarily has to be aware of it. We ended up ditching the standard C++ library's version of string, and used STLPort so we could control the library. I envision this same sort of problem would be likely with D collection objects that were not used via interfaces. I see no problem retrofitting a no-interface container into a formal interface if so needed. I don't understand this discussion: isn't the reason above pretty much a dead-on hard requirement for the collections to have interfaces? Something like, for example, an interface version of the range traits? Only if you wish to have binary compatibility with dynamic libs. Such a thing isn't likely today since dynamic libs aren't very well supported in D, and even phobos or dcollections isn't a dynamic lib. Ah, nevermind, my mind slipped and I was thinking of any kind of library, that is, static ones as well. Although even just dynamic library compatibility seems to be a valid enough case that we should consider from the start, even if its not well supported currently. -- Bruno Medeiros - Software Engineer
Re: dcollections 1.0 and 2.0a beta released
On Fri, 28 May 2010 06:24:26 -0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 27/05/2010 11:32, Steven Schveighoffer wrote: On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 24/05/2010 16:45, Andrei Alexandrescu wrote: In the past I have built a C++ library that abstracted features of the OS. My goal was to make it possible to dynamically load a module that abstracted things like setting the IP address of a network interface. My modules used std::string instead of char * to lookup services to get objects that implement the interface. Big mistake. On a later version of the standard C++ runtime, the private implementation of std::string changed, so the dynamically loaded libraries crashed horribly. No change in string's interface, just the private stuff changed, but because it's a template, the code that uses it necessarily has to be aware of it. We ended up ditching the standard C++ library's version of string, and used STLPort so we could control the library. I envision this same sort of problem would be likely with D collection objects that were not used via interfaces. I see no problem retrofitting a no-interface container into a formal interface if so needed. I don't understand this discussion: isn't the reason above pretty much a dead-on hard requirement for the collections to have interfaces? Something like, for example, an interface version of the range traits? Only if you wish to have binary compatibility with dynamic libs. Such a thing isn't likely today since dynamic libs aren't very well supported in D, and even phobos or dcollections isn't a dynamic lib. Ah, nevermind, my mind slipped and I was thinking of any kind of library, that is, static ones as well. Although even just dynamic library compatibility seems to be a valid enough case that we should consider from the start, even if its not well supported currently. I agree, that's why dcollections has interfaces. I'm keeping them there since std.container has gone its own direction. -Steve
Re: dcollections 1.0 and 2.0a beta released
On Fri, 28 May 2010 06:10:49 -0400, Jacob Carlborg d...@me.com wrote: On 2010-05-27 12:32, Steven Schveighoffer wrote: On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 24/05/2010 16:45, Andrei Alexandrescu wrote: In the past I have built a C++ library that abstracted features of the OS. My goal was to make it possible to dynamically load a module that abstracted things like setting the IP address of a network interface. My modules used std::string instead of char * to lookup services to get objects that implement the interface. Big mistake. On a later version of the standard C++ runtime, the private implementation of std::string changed, so the dynamically loaded libraries crashed horribly. No change in string's interface, just the private stuff changed, but because it's a template, the code that uses it necessarily has to be aware of it. We ended up ditching the standard C++ library's version of string, and used STLPort so we could control the library. I envision this same sort of problem would be likely with D collection objects that were not used via interfaces. I see no problem retrofitting a no-interface container into a formal interface if so needed. I don't understand this discussion: isn't the reason above pretty much a dead-on hard requirement for the collections to have interfaces? Something like, for example, an interface version of the range traits? Only if you wish to have binary compatibility with dynamic libs. Such a thing isn't likely today since dynamic libs aren't very well supported in D, and even phobos or dcollections isn't a dynamic lib. I've got my patch, for build Tango as a dynamic library on Mac, quite recently included in trunk. And I've also have a patch for druntime and Phobos in bugzilla just waiting to be included + one patch making it easier creating dynamic libraries directly with DMD. I would say it's a bad idea to still think that dynamic libraries aren't support, we have to think forward and assume they will be supported. I remember that, and I'm very encouraged by it. That being said, the ultimate goal is to have dmd be able to build dynamic libraries easily. D has had dynamic library support for years, but you have to do all kinds of manual stuff, and the standard library isn't dynamic. Until the standard library is dynamic, and I can build a dynamic library with a -shared equivalent switch, dynamic libs are a laboratory feature, and not many projects will use it. Just so you know, I think it's important to support binary compatibility in dcollections, and since std.container has not adopted dcollections, I'm going to keep interfaces. I was just pointing out the position others may have WRT binary support. -Steve
Re: Bug fix week
Bruno Medeiros さんは書きました: On 26/05/2010 21:14, Masahiro Nakagawa wrote: On Sun, 23 May 2010 22:50:14 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: We've had a tremendous infusion of talent and energy in Phobos, and lately work has picked up in unprecedented ways, both in terms of new features and bug fixes. I can't say how happy I am about that! At the end of this starting week, on Friday May 28, TDPL will be out on trucks to bookstores. Let's make this week a bug fixing week for both dmd and Phobos, and issue a release on Monday. We're going public! Andrei I think we need improvement of DDoc. Current DDoc doesn't keep up with D Spec(e.g. ignore @attribute, pure, etc...). I very much agree with this. I agree too. DDoc really lacks details of D2's key features. And those features are not used even in Phobos. Therefore, the features that does not understand how to use. In particular, I paid attention to shared, but I could not have any good idea. Please make key features clear, and describe documentation. Otherwise, no one will bring even one problem up. I let Phobos support @safe, and I enumerated some problems last time. See also: http://lists.puremagic.com/pipermail/phobos/2010-May/000488.html Following this, shared, Range, pure, nothrow, etc... should be used in fact, too, and should be evaluated.
D Programlama Dili is almost finished
It is a Turkish D2 book. I know that this news is not very useful for the members of this forum, but I am proud to announce that my D book targeting the Turkish reader is almost complete. It is for the novice programmer. Complete with exercises and solutions, it starts with the assignment operator and gradually builds other concepts. (I must say that D is an easy language to teach to novice programmers.) Since starting in July 2009, I've been making the chapters freely available at http://ddili.org/ders/d/ The free pdf version is around 520 pages these days. After finishing the final two chapters, I will get back to bringing the information up to date, e.g. the new operator overloading syntax should replace the old one. On a personal note, as far as I know, this book has been the first in computer technology where Turkish precedes any similar work in English. :) Thank you, Ali
Re: D Programlama Dili is almost finished
Ali Çehreli wrote: It is a Turkish D2 book. I know that this news is not very useful for the members of this forum, but I am proud to announce that my D book targeting the Turkish reader is almost complete. It is for the novice programmer. Complete with exercises and solutions, it starts with the assignment operator and gradually builds other concepts. (I must say that D is an easy language to teach to novice programmers.) Since starting in July 2009, I've been making the chapters freely available at http://ddili.org/ders/d/ The free pdf version is around 520 pages these days. After finishing the final two chapters, I will get back to bringing the information up to date, e.g. the new operator overloading syntax should replace the old one. On a personal note, as far as I know, this book has been the first in computer technology where Turkish precedes any similar work in English. :) Thank you, Ali This is great work, and thanks for adding the google translator widget too! I put a link http://www.digitalmars.com/d/2.0/index.html and on http://twitter.com/D_Programming
Re: D Programlama Dili is almost finished
On Fri, 28 May 2010 10:40:57 -0700, Ali Çehreli wrote: It is a Turkish D2 book. I know that this news is not very useful for the members of this forum, but I am proud to announce that my D book targeting the Turkish reader is almost complete. Congratulations! :)
D Programming now on twitter
http://twitter.com/D_Programming also use #d_lang to connect D related tweets
OT: Use of D-icon
Am 28.05.2010 20:06, schrieb Walter Bright: http://twitter.com/D_Programming also use #d_lang to connect D related tweets OT: I'm working on a redesign for wiki4d. Now I've seen the D-logo on twitter and I like it. :) Can we use this picture for wiki4d? greets Matthias
Re: OT: Use of D-icon
Matthias Pleh wrote: Am 28.05.2010 20:06, schrieb Walter Bright: http://twitter.com/D_Programming also use #d_lang to connect D related tweets OT: I'm working on a redesign for wiki4d. Now I've seen the D-logo on twitter and I like it. :) Can we use this picture for wiki4d? That was submitted by a user many years ago, the problem is I lost track of who it was. But I do recall he meant it to be used, so go ahead.
Re: OT: Use of D-icon
Matthias Pleh: I'm working on a redesign for wiki4d. Now I've seen the D-logo on twitter and I like it. :) I agree, it's nice looking, almost professional :-) I am thinking about using it on my site to link to D site. Other D logos look too much amateurish. Bye, bearophile
new layout on wiki4d
I have renewed the layout of the wiki4d-site. It's not finished, but I think it is already useable! Content itself hasn't changed! Any thoughts? Please check also the links on the sidebar! I have taken this from a template from Justin Calvarese (thanks), so maybe some links should changed, reordered or even removed! greets Matthias
Re: new layout on wiki4d
On 05/28/2010 07:47 PM, Matthias Pleh wrote: I have renewed the layout of the wiki4d-site. It's not finished, but I think it is already useable! Content itself hasn't changed! Any thoughts? Please check also the links on the sidebar! I have taken this from a template from Justin Calvarese (thanks), so maybe some links should changed, reordered or even removed! greets Matthias Awesome!!!
Re: new layout on wiki4d
Matthias Pleh wrote: I have renewed the layout of the wiki4d-site. It's not finished, but I think it is already useable! Content itself hasn't changed! Any thoughts? Please check also the links on the sidebar! I have taken this from a template from Justin Calvarese (thanks), so maybe some links should changed, reordered or even removed! greets Matthias Oh, wow. I'd been watching you make changes, didn't realize this was the result. Really nice work.
Memory Mapped File Access
Hi, has anyone played around with D and memory mapped files on Windows / Linux? A friend of mine and I want to use D to develop a D native database-system. Yes, sounds crazy and it will take long and we haven't done a lot yet. So don't expect anything to look at soon :-) Thanks Robert.
Re: Bug fix week
On 26/05/2010 21:14, Masahiro Nakagawa wrote: On Sun, 23 May 2010 22:50:14 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: We've had a tremendous infusion of talent and energy in Phobos, and lately work has picked up in unprecedented ways, both in terms of new features and bug fixes. I can't say how happy I am about that! At the end of this starting week, on Friday May 28, TDPL will be out on trucks to bookstores. Let's make this week a bug fixing week for both dmd and Phobos, and issue a release on Monday. We're going public! Andrei I think we need improvement of DDoc. Current DDoc doesn't keep up with D Spec(e.g. ignore @attribute, pure, etc...). I very much agree with this. -- Bruno Medeiros - Software Engineer
Re: Memory Mapped File Access
Robert Wrote: Hi, has anyone played around with D and memory mapped files on Windows / Linux? A friend of mine and I want to use D to develop a D native database-system. Yes, sounds crazy and it will take long and we haven't done a lot yet. So don't expect anything to look at soon :-) Thanks Robert. MMapped files work just fine, I played/am playing with them. I greet your idea to learn how to build database, its great way to spend time for people programming that stuff. And you are right - trying to make operational database like this is crazy, crazy idea. It will require from you HUGE investment in time learning to make it remotely reliable and usable. Here I talk about ACID compliance. If you are trying to build something that works *mostly* of the time and saves key - value pairs in file then it is much simpler. SQLite is a great project you could learn a lot from. It has tons of useful docs about making DB, its open source, its been around for 10 years and its probably better job then you could ever do.
Re: std.container update
BTW, what would be the point of an array/vector when you have built-in arrays? If built-in arrays would be syntax sugar for a real library type, like AAs, I can see as a good option using Array for that type, since built-in arrays and the library Array would be the same thing. The biggest difference is that a vector has capacity separate from its size/length. You can efficiency insert elements at the end with a vector - amortized constant time usually - but you can't do that with a built-in array because it would have to reallocate every time. D's arrays are fantastic, but they're still not quite good enough to outright replace a vector type. On top of that, of course, there's the issue of the API used to interact with it, which is what we're getting with std.container, but that could probably be gotten around in much the same way as the range stuff was with std.array. Really, the big difference is that you can efficiently append to a vector type while you cannot do that with an array. The array is still a tad too low level. And since you do need that low levelness at least some of the time (particularly in a systems language), it's not like you could replace arrays with vectors or make them act more like vectors. Both types have their uses. - Jonathan M Davis
Re: std.container update
Simen kjaeraas wrote: I take it you don't work in simulation or games, then? Don't do much linear algebra? While I understand the reasoning for it, I dislike the name vector for arrays. A vector to me, is a geometric object with a length and magnitude, not a random collection of whatevers. Vector is arguably a poor name because of that. However, it is, at this point, a very standard name for such a container. At minimum, both C++ and Java have a vector class, though the main one that you'd use in Java at this point would be ArrayList rather than Vector. So, if a better name can be found, that's great, but Vector is quite a standard name for the concept at this point, and I do think that it works better than Array. I also don't like the name ArrayList because I wouldn't really consider a vector to be a list, but that's another option. I'm not all that familiar with what other languages have used for such a class, but there are probably other pre- existing options out there as well. - Jonathan M Davis
Re: std.container update
Jonathan M Davis: The biggest difference is that a vector has capacity separate from its size/length. You can efficiency insert elements at the end with a vector - amortized constant time usually - but you can't do that with a built-in array because it would have to reallocate every time. D's arrays are fantastic, but they're still not quite good enough to outright replace a vector type. I can think about the opposite too: to remove the built-in dynamic arrays and replace them as it's being done with associative arrays, keeping only the syntax sugar and mapping them to the Array/Vector. Is this a bad idea? (this is only about dynamic arrays, at the moment built-in fixed-sized arrays have to be kept). Bye, bearophile
Re: Bug fix week
Lutger Wrote: What is the purpose of votes for closed bugs anyway? Should they not just get removed automatically? I would love if bugs get fixed automatically.
Re: Shared Class Variables
sybrandy Wrote: Evening. I'm having a bit of a problem and I'm hoping someone can help. I'm trying to create a class that is shared across threads. The only purpose of this class is to write data to somewhere, though currently a file. A single-threaded version of this works fine, however I can't seem to get the code to work correctly when dealing with multiple threads. I've gotten sharing issues, compilation issues trying to figure out how to use a shared class correctly, and currently an exception occurring during class finalization. So, my question is, what is the correct way to do this? Would a class work or would a struct be better? Perhaps a singleton? Class methods must be marked as shared and object must be stored and passed as shared. But you still must not screw up the object's data in race condition and use proper syncronization when necessary. Marking data as shared doesn't do much - it's kinda synonym for volatile.
Re: std.container update
Jonathan M Davis, el 28 de mayo a las 04:58 me escribiste: BTW, what would be the point of an array/vector when you have built-in arrays? If built-in arrays would be syntax sugar for a real library type, like AAs, I can see as a good option using Array for that type, since built-in arrays and the library Array would be the same thing. The biggest difference is that a vector has capacity separate from its size/length. You can efficiency insert elements at the end with a vector - amortized constant time usually - but you can't do that with a built-in array because it would have to reallocate every time. D's arrays are fantastic, but they're still not quite good enough to outright replace a vector type. OK, I forgot that, I guess my brain choose to forget it to stop keeping the flame alive, so I'll forget all about it again =P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Estamos cantando a la sombra de nuestra parra una canción que dice que uno sólo conserva lo que no amarra
Re: std.container update
On Fri, 28 May 2010 07:58:55 -0400, Jonathan M Davis jmdavisp...@gmail.com wrote: BTW, what would be the point of an array/vector when you have built-in arrays? If built-in arrays would be syntax sugar for a real library type, like AAs, I can see as a good option using Array for that type, since built-in arrays and the library Array would be the same thing. The biggest difference is that a vector has capacity separate from its size/length. You can efficiency insert elements at the end with a vector - amortized constant time usually - but you can't do that with a built-in array because it would have to reallocate every time. D's arrays are fantastic, but they're still not quite good enough to outright replace a vector type. This isn't exactly true. D's builtin arrays also are amortized constant time to append, but the constant is way higher :) I agree that an array-like container would provide features that D's builtin arrays do not, including much better append performance. -Steve
Re: Bug fix week
Bruno Medeiros さんは書きました: On 26/05/2010 21:14, Masahiro Nakagawa wrote: On Sun, 23 May 2010 22:50:14 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: We've had a tremendous infusion of talent and energy in Phobos, and lately work has picked up in unprecedented ways, both in terms of new features and bug fixes. I can't say how happy I am about that! At the end of this starting week, on Friday May 28, TDPL will be out on trucks to bookstores. Let's make this week a bug fixing week for both dmd and Phobos, and issue a release on Monday. We're going public! Andrei I think we need improvement of DDoc. Current DDoc doesn't keep up with D Spec(e.g. ignore @attribute, pure, etc...). I very much agree with this. I agree too. DDoc really lacks details of D2's key features. And those features are not used even in Phobos. Therefore, the features that does not understand how to use. In particular, I paid attention to shared, but I could not have any good idea. Please make key features clear, and describe documentation. Otherwise, no one will bring even one problem up. I let Phobos support @safe, and I enumerated some problems last time. See also: http://lists.puremagic.com/pipermail/phobos/2010-May/000488.html Following this, shared, Range, pure, nothrow, etc... should be used in fact, too, and should be evaluated.
Re: std.container update - now Array is in
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article: I defined Array as a straightforward implementation of the homonym abstraction. There are a few imperfect corners, but by and large I'm starting to believe it's becoming possible to write certain cross-container codes. I think it might be a good idea is to make it so that, for struct types, when they're removed from the containers, their destructors are run[1]. That way containers would be able to work with some kinds of smart pointer abstractions once the compiler is up to supporting them, which would make both the containers and the smart pointers a good deal more useful. Cheers, Pillsy [1] I asked some questions about the feasibility of this in d.learn.
Re: std.container update - now Array is in
On Thu, 27 May 2010 21:08:29 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: http://erdani.com/d/phobos/std_container.html http://erdani.com/d/phobos/container.d I defined Array as a straightforward implementation of the homonym abstraction. There are a few imperfect corners, but by and large I'm starting to believe it's becoming possible to write certain cross-container codes. I just noticed, there is no doc for ElementType, only ValueType and KeyType. -Steve
Re: std.container update - now Array is in
On Fri, 28 May 2010 15:51:53 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 27 May 2010 21:08:29 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
http://erdani.com/d/phobos/std_container.html
http://erdani.com/d/phobos/container.d
I defined Array as a straightforward implementation of the homonym
abstraction. There are a few imperfect corners, but by and large I'm
starting to believe it's becoming possible to write certain
cross-container codes.
I just noticed, there is no doc for ElementType, only ValueType and
KeyType.
Also, ElementType is also a template in std.range, can we change one of
these? I would use the following condition to accept a range:
struct container(T)
{
void add(R)(R r) if (isInputRange!R
isImplicitlyConvertible(ElementType!R, T)
}
But I think if container(T) defines ElementType, the compiler will be
confused...
-Steve
Re: Bug fix week
Bruno Medeiros wrote: On 26/05/2010 21:14, Masahiro Nakagawa wrote: On Sun, 23 May 2010 22:50:14 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: We've had a tremendous infusion of talent and energy in Phobos, and lately work has picked up in unprecedented ways, both in terms of new features and bug fixes. I can't say how happy I am about that! At the end of this starting week, on Friday May 28, TDPL will be out on trucks to bookstores. Let's make this week a bug fixing week for both dmd and Phobos, and issue a release on Monday. We're going public! Andrei I think we need improvement of DDoc. Current DDoc doesn't keep up with D Spec(e.g. ignore @attribute, pure, etc...). I very much agree with this. Bug 3445 seems to be the most important.
Re: std.container update - now Array is in
On 05/28/2010 02:51 PM, Steven Schveighoffer wrote: On Thu, 27 May 2010 21:08:29 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: http://erdani.com/d/phobos/std_container.html http://erdani.com/d/phobos/container.d I defined Array as a straightforward implementation of the homonym abstraction. There are a few imperfect corners, but by and large I'm starting to believe it's becoming possible to write certain cross-container codes. I just noticed, there is no doc for ElementType, only ValueType and KeyType. -Steve I figured out that ElementType is actually unneeded - introspection can extract it for you, see std.range.ElementType. Andrei
Re: std.container update - now Array is in
On Fri, 28 May 2010 16:03:10 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 05/28/2010 02:51 PM, Steven Schveighoffer wrote: On Thu, 27 May 2010 21:08:29 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: http://erdani.com/d/phobos/std_container.html http://erdani.com/d/phobos/container.d I defined Array as a straightforward implementation of the homonym abstraction. There are a few imperfect corners, but by and large I'm starting to believe it's becoming possible to write certain cross-container codes. I just noticed, there is no doc for ElementType, only ValueType and KeyType. -Steve I figured out that ElementType is actually unneeded - introspection can extract it for you, see std.range.ElementType. Well, the docs still use ElementType everywhere. I don't really know how it would be introspected, what common function are all containers expected to implement (analogous to front() in a range)? The only thing I would suggest is that having ElementType or something equivalent, would help with documentation, since ddoc would be immune to said introspection. -Steve
Re: Memory Mapped File Access
On 2010-05-28 13:06:04 +0200, Bane branimir.milosavlje...@gmail.com said: MMapped files work just fine, I played/am playing with them. I posted before I saw that there is a MmFile class :-) So, I have the first questions: 1. How can I expand the size of a MMF after it was created? 2. If I specify 100GB file-size will it always be written once to disk even if there is nothing in it? Or does the OS use sparse-files as well? I greet your idea to learn how to build database, its great way to spend time for people programming that stuff. And you are right - trying to make operational database like this is crazy, crazy idea. It will require from you HUGE investment in time learning to make it remotely reliable and usable. Here I talk about ACID compliance. If you are trying to build something that works *mostly* of the time and saves key - value pairs in file then it is much simpler. Ok, I need to be fair. We are quite good at these things. Anyone remembering Adimens from the Atari (later for Windows as well)? It was/is a ACID compliant SQL database with row-level locking etc. And, it was written by my friend and sold more than 500.000 times. Yes, we are crazy... but chances are high we will get something done. I need to get some practice with D but shouldn't be that hard. SQLite is a great project you could learn a lot from. It has tons of useful docs about making DB, its open source, its been around for 10 years and its probably better job then you could ever do. Yep, I use it since several years. A great piece of software. -- Robert
Re: Shared Class Variables
I don't know much about threading but I do know that D1 vs. D2 (you didn't say what version) makes a big difference. For example, in D2 globals are thread local by default where as in D1 they are not. Thanks. Casey Sorry about that. I've been doing everything in D2. Casey
Huffman coding comparison
Now and then it's very useful to compare how to write in D2 a small interesting
program written in another language, the comparison can help find problems,
possible improvements, performance problems, and so on.
Time ago I have tried to convert to D2 a small Python program that finds the
Huffman encoding of a given string, but Phobos2 was not mature enough, and I
didn't produce a good enough D2 program. I have tried again and this time
things are good enough.
The original Python code comes from the rosettacode site (that contains
comparisons of many different programs implemented in many different
languages), the point of the Python version is not performance, but to show
elegant compact code (there are ways to write this code shorter in Python but
this code must has to be readable, it's not a code golf site).
This the Python 2.x version:
from heapq import heappush, heappop, heapify
from collections import defaultdict
def encode(symb2freq):
Huffman encode the given dict mapping symbols to weights
heap = [[float(wt), [sym, ]] for sym, wt in symb2freq.iteritems()]
heapify(heap)
while len(heap) 1:
lo = heappop(heap)
hi = heappop(heap)
for pair in lo[1:]:
pair[1] = '0' + pair[1]
for pair in hi[1:]:
pair[1] = '1' + pair[1]
heappush(heap, [lo[0] + hi[0]] + lo[1:] + hi[1:])
return sorted(heappop(heap)[1:], key=lambda p: (len(p[1]), p))
txt = this is an example for huffman encoding
symb2freq = defaultdict(int)
for ch in txt:
symb2freq[ch] += 1
huff = encode(symb2freq)
print Symbol\tWeight\tHuffman Code
for p in huff:
print %s\t%s\t%s % (p[0], symb2freq[p[0]], p[1])
It contains a demo string, and it prints (tabs set to 4 spaces):
Symbol Weight Huffman Code
6 101
n 4 010
a 3 1001
e 3 1100
f 3 1101
h 2 0001
i 3 1110
m 2 0010
o 2 0011
s 2 0111
g 1 0
l 1 1
p 1 01100
r 1 01101
t 1 1
u 1 10001
x 1 0
c 1 10
d 1 11
After few experiments I have produced this working D2 version that uses just
Phobos2:
import std.stdio, std.algorithm, std.typecons;
/// Huffman encode the given dict mapping symbols to weights
auto encode(TFreq, TSymb)(TFreq[TSymb] symb2freq) {
alias Tuple!(TSymb, symb, string, code) Pair;
alias Tuple!(TFreq, freq, Pair[], pairs) Block;
Block[] blocks;
foreach (symb, freq; symb2freq)
blocks ~= Block(freq, [Pair(symb, )]);
auto heap = BinaryHeap!(Block[], b a)(blocks);
while (heap.length 1) {
auto lo = heap.pop(1)[0];
auto hi = heap.pop(1)[0];
foreach (ref pair; lo.pairs)
pair.code = '0' ~ pair.code;
foreach (ref pair; hi.pairs)
pair.code = '1' ~ pair.code;
heap.push(Block(lo.freq + hi.freq, lo.pairs ~ hi.pairs));
}
auto r = heap.pop(1)[0].pairs;
schwartzSort!((x){ return x.code.length; })(r);
return r;
}
void main() {
auto txt = this is an example for huffman encoding;
int[char] symb2freq;
foreach (c; txt)
symb2freq[c]++;
auto huff = encode(symb2freq);
writeln(Symbol\tWeight\tHuffman Code);
foreach (p; huff)
writefln(%s\t%s\t%s, p.symb, symb2freq[p.symb], p.code);
}
That prints:
Symbol Weight Huffman Code
n 4 010
6 101
a 3 1001
e 3 1100
o 2 0011
i 3 1110
h 2 0001
f 3 1101
s 2 0111
m 2 0010
t 1 1
g 1 0
r 1 01101
p 1 01100
l 1 1
u 1 10001
x 1 0
d 1 11
c 1 10
Some notes (later I can send them to Andrei):
The D2 version is longer, but this size difference can be acceptable. The D2
version looks good enough (this is just a small test program. In a real D2
program I write code in a less compressed way, I add comments, preconditions,
unittests, and when it's necessary I try to write more efficient code).
It is not fully equivalent to the Python version, to print the same thing the
Schwartz sorting has to use (x){return tuple(x.code.length, x);}.
For me for one thing the D program is better than the Python version: the
Python std lib doesn't define a mutable named tuple like that one in D2 (there
is only one immutable and dynamically typed one), this forces the Python code
to use all those [0] and [1:]. Anonymous structures sometimes make Python code
shorter, but they can be less explicit too. Of course it's easy to define in
Python a function like Tuple of Phobos2 that accepts optional field names too.
The std.typecons module, that contains Tuple and tuple can be named something
simpler to remember as std.tuples.
I will keep missing array comprehensions in D. In the meantime other languages
have got some forms of them (but Python ones use the best syntax still).
In translating the program I have not found significant problems. The only bug
I have found was caused by the different ordering of the Python/Phobos2
Re: Static constructors in circularly imported modules - again
On 27.05.2010 13:37, Max Samukha wrote:
There was a discussion about those a while ago that terminated with
Andrei's authoritative it would be a step backward.
I am not entirely convinced that there had been a step forward in the
first place. Defining static construction order to be determined by the
module import graph had been a half step forward. Completely disallowing
static construction of circularly imported modules - a half step
backward. The result is std.stdiobase and impossibility to initialize
static data in mixins without resorting to lazy initialization.
I can live with hacks like std.stdiobase when such are possible. What is
more critical is initialization of mixins. Restating the problem:
module a;
mixin template Foo()
{
static immutable Object foo;
shared static this()
{
foo = cast(immutable)new Object;
}
}
module b;
import a;
import c;
mixin Foo;
module c;
import a;
import b;
mixin Foo;
In this scenario one is forced to avoid static constructors by lazily
initializing foo and using some kind of synchronization, which should be
absolutely unnecessary and sometimes is not tolerable.
So which of the following is going to happen?
1. The current blinkered design will stay.
2. A solution will be provided before D2 is feature-freezed.
Feature-frozen. Sorry.
Note that I am well aware of
http://yosefk.com/c++fqa/ctors.html#fqa-10.12 etc, but simply
disallowing static construction is not a good solution for static
construction problems.
I'd really appreciate a reply from the language designers. What are the
plans?
1. Static constructor semantics won't change.
2. We've worked out a solution and it will be implemented in a future
compiler release.
Please care to type 1 or 2. Thank you!
C#5 desiderata
You can remember when I have shown this link, about desired features for C#4:
http://stackoverflow.com/questions/138367/
Instead of many of those features, C# devs have chosen to add only very few
ones, but rather basic ones, like the dynamic attribute, that change some how
C# programs can be written.
Recently a similar question has appeared about C#5 (probably some answers are
repeated from the precedent thread):
http://stackoverflow.com/questions/2875533/
Some of those things are meaningful only in the context of C#4.
Note: what follows below is not my list of desiderata for D2/D3, it's just a
summarized version of that that stackoverflow thread about C#5 desiderata.
---
Return tuples:
public (int, string, double) Foo() {
return (42, foo, 4.2);
return {Hello World, 42, 4.2};
}
// elsewhere: item1 is a string, item2 is an int, item3 is a double.
var (item1, item2, item3) = Foo();
var {item1, item2, item3} = Foo();
var myTuple = (42, foo, 4.2);
var myTuple = {42, foo, 4.2};
===
Tupleint, string, double myTuple = Tuple.Create(42, foo, 4.2);
---
in for arrays:
if (x in (1, 2, 3)) {}
---
Automatic Flag Enums (automatically enumerate in powers of two).
---
Null Safe Member Operator:
Instead of doing:
var obj = Foo();
Bar value = null;
if (obj.Bar != null obj.Bar.Something != null)
value = obj.Bar.Something.DoSomething();
You can do this with Groovy's null safe member operator:
var obj = Foo();
var value = obj?.Bar?.Something?.DoSomething();
---
Nested Iterators:
public override IEnumerableint Foo() {
yield return 1;
yield return 2;
yield return base.Foo();
// yield foreach base.Foo();
}
Instead of:
public override IEnumerableint Foo() {
yield return 1;
yield return 2;
foreach(var i in base.Foo()) yield i;
}
As explained here too:
http://research.microsoft.com/en-us/projects/specsharp/iterators.pdf
---
Weak delegates, to make it easy to implement weak events. A modifier like ~
could mark a normal delegate weak:
public event EventHandler StrongEvent;
public event EventHandler~ WeakEvent; // Shortcut for WeakDelegateEventHandler
---
Arrays indexed by enums, delphi style:
enum Weekdays { Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday }
private int[Weekdays] dayFun = new [] { 0, 0, 1, 1, 3, 10, 8 };
// later..
mondayFun = dayFun[Weekdays.Monday];
---
Exception grouping to avoid duplicating the same handling logic
try
{
}
catch (ArgumentOutOfRangeException)
catch (ArgumentNullException)
{
// Catch a ArgumentOutOfRangeException or a ArgumentNullException
}
(I think this syntax can be improved, just using the comma).
---
@memoize
Or something similar user-defined. It is really useful, to avoid coding true
dynamic programming algorithms.
---
as operator for objects (This is already present in C#4).
Bye,
bearophile
Re: C#5 desiderata
bearophile bearophileh...@lycos.com wrote:
Return tuples:
Absolutely. While it's possible today, some more sugar wouldn't hurt.
in for arrays:
Yes.
Automatic Flag Enums (automatically enumerate in powers of two).
Neat. Worthy an @keyword, I think. @flag enum foo {...}
Null Safe Member Operator:
var value = obj?.Bar?.Something?.DoSomething();
I feel this is a tad too sweet. On the one hand I like it, on the
other I feel it will lead to bugs at a later point, by hiding null
pointers and not teaching programmers to deal with them.
Add a ? to all object accesses. It is magical and removes bugs.
Weak delegates, to make it easy to implement weak events.
From what I read about this, it seems nice, but also possible to
implement with current metaprogramming capabilities. Given an
event system, what are the advantages to language support for
this?
Arrays indexed by enums, delphi style:
This seems to work for me in D2. But you probably meant an array
that has exactly the same number of elements as has the enum.
I can imagine this being a problem with enums having completely
random values (which they may). That might be even more of an
argument for @flag, as mentioned above. If n...@flag enums may
not expose internal details such as equivalent values, while
@flags may (to allow for composite flag shortcuts), you could
easily allow this for n...@flag enums.
Also, manifest constants should have a different name than
'enum', as they have nothing to do with enums.
Exception grouping to avoid duplicating the same handling logic
Very nice.
@memoize
Or something similar user-defined. It is really useful, to avoid coding
true dynamic programming algorithms.
This again is to sweet for me. What does @memoize do? Does it
store the last 5 results? All results? The last result only?
Does it depend on the phase of the moon, time of day and what
socks I'm wearing?
as operator for objects (This is already present in C#4).
So a as b rather than cast(b)(a) or to!(b)(a)? Or is there
some other magic at work that I don't see?
--
Simen
Re: C#5 desiderata
Simen kjaeraas:
I think you have missed one important point: that was not my list of things I'd
like in D2/D3. It contains some cute things, but it's first of all a summary of
the linked stackoverflow thread. My personal list of desiderata for D3 is
different.
Absolutely. While it's possible today, some more sugar wouldn't hurt.
I think Walter said this can't be implemented :)
The items alignment of function arguments used by D tuples is not fitting to
return a struct. I have not understood the details of this thing, and in the
end I don't care if returning a struct can decrease performance a bit...
in for arrays:
Yes.
I think Walter doesn't like this because he thinks in has to always look for
keys, and keys of an array are its indexes. I don't agree with Walter here, but
I don't think he will change his mind soon.
Neat. Worthy an @keyword, I think. @flag enum foo {...}
It's cute. But Don hates attributes :-) Recently I have created a thread about
this, and some one has written a good enough implementation in normal D code,
that can be good enough.
I feel this is a tad too sweet. On the one hand I like it, on the
other I feel it will lead to bugs at a later point, by hiding null
pointers and not teaching programmers to deal with them.
Add a ? to all object accesses. It is magical and removes bugs.
I agree. It can be handy but it can lead to bugs too, so I don't know what to
think about it.
Given an event system, what are the advantages to language
support for this?
I don't know.
Exception grouping to avoid duplicating the same handling logic
Very nice.
I have proposed something similar time ago. Python uses a tuple of possible
exceptions, I was not expecting D to allow only one of them. Some form of this
can be added to D2.
@memoize
Or something similar user-defined. It is really useful, to avoid coding
true dynamic programming algorithms.
This again is to sweet for me. What does @memoize do? Does it
store the last 5 results? All results? The last result only?
Does it depend on the phase of the moon, time of day and what
socks I'm wearing?
That's why I have said user-defined (in Python too it's user defined), so you
can define and use the one you prefer. But currently D properties are not
flexible enough to allow programmers to define them.
So a as b rather than cast(b)(a) or to!(b)(a)? Or is there
some other magic at work that I don't see?
I think there is no magic, it's just syntax sugar.
Bye,
bearophile
Re: Huffman coding comparison
bearophile, el 28 de mayo a las 18:01 me escribiste: For me for one thing the D program is better than the Python version: the Python std lib doesn't define a mutable named tuple like that one in D2 (there is only one immutable and dynamically typed one), this forces the Python code to use all those [0] and [1:]. Anonymous structures sometimes make Python code shorter, but they can be less explicit too. Of course it's easy to define in Python a function like Tuple of Phobos2 that accepts optional field names too. Just for fun :) def NamedTuple(*fields): class T: def __init__(self, *args): for i in range(len(args)): setattr(self, fields[i], args[i]) return T Pair = NamedTuple(symb, code) Block = NamedTuple(freq, pair) p = Pair(1, 2) b = Block(3, p) print p.symb, p.code, b.freq, b.pair.symb, b.pair.code I will keep missing array comprehensions in D. In the meantime other languages have got some forms of them (but Python ones use the best syntax still). They are wonderful, and it's *very* hard to get used to live in a language that doesn't support them once you start using it often. PS: Sorry about the Python-love mail... =P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Lidiar no es lo mismo que holguear; ya que lidiar es relativo a lidia y holguear es relativo a olga. -- Ricardo Vaporeso
Re: C#5 desiderata
On 5/28/10, bearophile bearophileh...@lycos.com wrote:
in for arrays:
if (x in (1, 2, 3)) {}
If the uniform function call syntax starts up, you could (maybe) do
something like this:
import std.algorithm;
import std.array;
bool among(T)(T v, T[] arr...) {
return ! (arr.find(v).empty);
}
if( x . among ( 1, 2, 3 ) ) { }
This doesn't work right now because you can't do property syntax on
ints, but this might work in the near future.
It does work if you're looking for an array:
hello . among ( world, hello, whatever ); // compiles and runs
correctly right now
I picked among here since it does what it means and isn't a reserved
word like in right now. The name doesn't really matter though.
Re: Huffman coding comparison
Leandro Lucarella: def NamedTuple(*fields): class T: def __init__(self, *args): for i in range(len(args)): setattr(self, fields[i], args[i]) return T That's not enough, those tuples must support the cmp for the heap. This barely works, but it's not good code yet: def NamedTuple(*fields): class Foo: def __init__(self, *args): for field, arg in zip(fields, args): setattr(self, field, arg) def __cmp__(self, other): return cmp([getattr(self, f) for f in fields], [getattr(other, f) for f in fields]) return Foo Bye, bearophile
Re: C#5 desiderata
On Fri, 28 May 2010 19:52:46 -0400, bearophile bearophileh...@lycos.com
wrote:
Simen kjaeraas:
Neat. Worthy an @keyword, I think. @flag enum foo {...}
It's cute. But Don hates attributes :-) Recently I have created a thread
about this, and some one has written a good enough implementation in
normal D code, that can be good enough.
Also, don't forget CTFE makes this simple to roll your own:
enum foo { bar = 1 0, bar2 = 11, ... }
Re: Huffman coding comparison
bearophile bearophileh...@lycos.com wrote:
I will keep missing array comprehensions in D. In the meantime other
languages have got some forms of them (but Python ones use the best
syntax still).
I'm now so tired of hearing this, I started writing something that
does it:
auto r = list!2 * a | [1,2,3,4,5] where!a 1 );
Takes any kind of range, and list and where are basically map and
filter in disguise. Only thing I did was add operator overloading.
Now, granted, I have little to no experience with list comprehension,
and as such this might not be what is needed. Still, it was fun to
play around with, and I kinda like what it turned out as.
import std.algorithm;
import std.range;
import std.array;
struct listImpl( alias pred ) {
auto opBinary( string op : |, Range )( Range other ) {
return map!pred(other);
}
}
struct whereImpl( alias pred ) {
auto opBinaryRight( string op : , R )( R range ) {
return filter!pred(range);
}
}
@property
whereImpl!pred where( alias pred )( ) {
whereImpl!pred result;
return result;
}
@property
listImpl!pred list( alias pred )( ) {
listImpl!pred result;
return result;
}
unittest {
assert( equal( list!2 * a | [1,2,3,4,5] where!a 1, [2,6,10] )
);
assert( equal( list!2 * a | [1,2,3], [2,4,6] ) );
}
--
Simen
Go has contempt for generics
http://www.reddit.com/r/programming/comments/c93iy/go_at_io_frequently_asked_questions/ Do you have plans to implement generics? Many proposals for generics-like features have been mooted both publicly and internally, but as yet we haven't found a proposal that is consistent with the rest of the language. We think that one of Go's key strengths is its simplicity, so we are wary of introducing new features that might make the language more difficult to understand. Additionally, the more Go code we write (and thus the better we learn how to write Go code ourselves), the less we feel the need for such a language feature. That has Java 1994 written all over it. Andrei
Re: C#5 desiderata
bearophile bearophileh...@lycos.com wrote:
Simen kjaeraas:
I think you have missed one important point: that was not my list of
things I'd like in D2/D3. It contains some cute things, but it's first
of all a summary of the linked stackoverflow thread. My personal list of
desiderata for D3 is different.
You are right indeed. I misread that first sentence to its exact
opposite. :p
I think Walter said this can't be implemented :)
I think Walter just doesn't want to implement it. :p
The items alignment of function arguments used by D tuples is not
fitting to return a struct.
Yeah. So, either we need thunks for this, or tuples need to carry
alignment information.
Neat. Worthy an @keyword, I think. @flag enum foo {...}
It's cute. But Don hates attributes :-) Recently I have created a thread
about this, and some one has written a good enough implementation in
normal D code, that can be good enough.
Screw Don. :p
In all seriousness though, the implementation in that thread is good
enough for me, and with the language change Andrei mentioned in the same
thread, I would be a happy panda.
--
Simen
Copy constructors for lazy initialization
Walter has had a great idea last night: allow classes to define
this(ref S src);
where S is the name of the struct being defined, as an alternative for
this(this);
The result would be a function similar with a C++ copy constructor.
Such an abstraction allows us to perform lazy initialization in a way
that allows the kind of problems associated with non-shared hash tables:
void foo(int[int] x)
{
x[5] = 5;
}
void main()
{
int[int] x;
foo(x);
assert(x[5] == 5); // fails
}
If you change the first line of main() with
int[int] x = [ 42:42 ];
the assert passes.
The idea of the copy constructor is to lazy initialize the source and
the target if the source has null state. That would take care of this
problem and the similar problems for shared state.
There is still a possibility to call a method against an object with
null state. I think that's acceptable, particularly because lazy
initialization saves some state allocation.
What do you think?
Andrei
Re: Huffman coding comparison
Simen kjaeraas: I'm now so tired of hearing this, I started writing something that does it: Array comprehensions are syntax sugar. From what I have seen there is a very narrow range of usable syntaxes for them. Outside that range, they get much less useful or useless. Even Haskell has got them sub-quality. At first sight they seem just able to allow you write one line of code instead of three or four, so no big deal. In practice they allow the programmer to turn those three lines of code into a single chunk. So the programmer can grasp and think about more code at the same time. This improves programming. The word 'chunk' comes from mind sciences, it's the thing referred to in the famous The Magical Number Seven, Plus or Minus Two, those are numbers of chunks. http://en.wikipedia.org/wiki/Chunking_%28psychology%29 Eventually Walter will understand that. Walter is sometimes slow in improving his understanding of things, but he never stops moving forward: I think his meta-learning capabilities are not high, but they are present and they are higher than most of other people you find around (that often have near zero meta-learning capabilities) :-) Bye, bearophile
Re: Go has contempt for generics
Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/c93iy/go_at_io_frequently_asked_questions/ Do you have plans to implement generics? Many proposals for generics-like features have been mooted both publicly and internally, but as yet we haven't found a proposal that is consistent with the rest of the language. We think that one of Go's key strengths is its simplicity, so we are wary of introducing new features that might make the language more difficult to understand. Additionally, the more Go code we write (and thus the better we learn how to write Go code ourselves), the less we feel the need for such a language feature. That has Java 1994 written all over it. Andrei I had a professor who felt that Java hadn't become a real language until it added generics. Things were too nice and neat before that. Now, there are a number of things - particularly surrounded generics - which are fairly complicated and nuanced in Java (frequently because they did generics by erasure). So, there's definitely more to trip you up, but it's more useful too. There are definitely choices which can be made with a language which reduce the number of programming errors, but there are a lot which also seriously restrict you. Sure, Java worked without generics. It works without function pointers too. But the lack of generics was frustrating, and the lack of function pointers is still frustrating. The ommission seems alsmost criminal. You _can_ do a lot with a really stripped down language, but if you strip out too much, it can be highly frustrating for the programmer, and it will likely lead to other types of bugs when programmers are forced to do things differently. But if Go doesn't have generics then that's a _huge_ difference from D, since D's templates are definitely some of the most powerful out there. And some of the language features - such as static if - make it possible to do stuff in D that would require template metaprogramming in C++, so D has actually simplified things by making the language more powerful. So, while some folks seem to want to draw comparisons between Go and D, it sounds like there are definitely things about them which are drastically different, not only in the design, but in the philosophy behind the design. - Jonathan M Davis
Re: C#5 desiderata
If there's one thing I need to agree with there, it's definitely having more than one return value. C/C++ have it really awful by passing pointers, and then you need to document it's an out parameter (I know this has become very common to most of us, me included, but when I first saw this - years and years ago - I was like WTF, parameters are defined as values going in - I think that looking at the first reaction of beginners can sometimes point you very directly at what doesn't make sense but that experienced programmers don't notice because they're used to it). D makes this a bit cleaner by having a out keyword; but still I feel that placing the first out value at the start of the function, then the second among the parameters with some special keyword is still grouping unrelated things, and splitting related ones. So, in short, +1 ;) But I know this won't happen for D2. Guess I had to say it anyway :)
Re: Go has contempt for generics
Andrei Alexandrescu: That has Java 1994 written all over it. Java today can be the most used language, so despite its faults, probably it was good enough. Even if Go has no templates, it has plenty of time to add them five years from now :-) (And in the end templates aren't the only way to design a type-generic language). Bye, bearophile
Re: C#5 desiderata
Simen kjaeraas: Yeah. So, either we need thunks for this, or tuples need to carry alignment information. If we accept a little less performance there must be a way to solve this problem. Multiple return values are certainly very handy. Bye, bearophile
Re: C#5 desiderata
I think Walter said this can't be implemented :) The items alignment of function arguments used by D tuples is not fitting to return a struct. I have not understood the details of this thing, and in the end I don't care if returning a struct can decrease performance a bit... well, it could just be sugar ;) e.g. : (int, int) doFoo(int x, int y) could perhaps automagically be re-written by the compiler as int doFoo(int x, int y, out int z)
Re: Copy constructors for lazy initialization
Andrei Alexandrescu wrote: What do you think? Andrei Certainly, in the case provided, it's a definite win. I'm not sure what the overall implications would be though. Part of the problem stems from the fact that the array is initialized to null, and yet you can still add stuff to it. My first reaction (certainly without having messed around with it in D) would be that x[5] = 5 would fail because the array was null. However, instead of blowing up, D just makes the null array into an empty one and does the assignment. If D didn't allow the assignment without having first truly created an empty array rather than a null one, then we wouldn't have the problem. Now, there may be very good reasons for the current behavior, and this suggestion would fix the problem as it stands. But it would still require the programmer to be aware of the issue and use this(ref S src) instead of this(this) if they were writing the constructor or be aware of which it was if they didn't write the constructor. Not knowing what other implications there are, I'm fine with the change, but the fact that D creates the array when you try and insert into it (or append to it in the case of normal arrays IIRC) rather than blowing up on null seems like a source of subtle bugs and that perhaps it's not the best design choice. But maybe there was a good reason for that that I'm not aware of, so it could be that it really should stay as-is. It's just that it seems danger-prone and that the situation that you're trying to fix wouldn't be an issue if the array stayed null until the programmer made it otherwise. - Jonathan M Davis
Re: Copy constructors for lazy initialization
Andrei Alexandrescu Wrote: this(ref S src); this(this); What do you think? In this moment I am too much sleepy to understand the semantics of what you say. But I can say something about syntax: that this(this) syntax is bad, it's cryptic, I prefer something that uses/contains some English word/name that I read and reminds me of what it does. The this(ref S src) syntax makes things even worse in this regard. Please don't turn D into a puzzle language (note that I am not saying your feature is bad, far from it, I am just saying that the syntax you have proposed is very far from being easy to understand from the way it is written). Regardless of what Don has said, here I'd probably like something like a readable @attribute to replace this(this) :-) Bye, bearophile
Re: Go has contempt for generics
bearophile wrote: Andrei Alexandrescu: That has Java 1994 written all over it. Java today can be the most used language, so despite its faults, probably it was good enough. Even if Go has no templates, it has plenty of time to add them five years from now :-) (And in the end templates aren't the only way to design a type-generic language). Bye, bearophile I'd argue that Java suffers from the fact that they added generics late in the game. Generics by erasure brings no benefits except backwards compatability, and they cause a whole host of problems for people trying to use them. Yes, you _can_ add things like generics into the language later, but it can be quite disruptive to do so, and the result could be subpar due to constraints such as backwards compatability. Sure, you _can_ use a language without generics (and many other features) and get a lot done, but I'd argue having simplicity as your prime directive tends to lead to an inefficient tool for the programmer. Simplicity should be a goal, but there are times that it should be overridden by other goals. - Jonathan M Davis
Re: Copy constructors for lazy initialization
bearophile wrote: Andrei Alexandrescu Wrote: this(ref S src); this(this); What do you think? In this moment I am too much sleepy to understand the semantics of what you say. But I can say something about syntax: that this(this) syntax is bad, it's cryptic, I prefer something that uses/contains some English word/name that I read and reminds me of what it does. The this(ref S src) syntax makes things even worse in this regard. Please don't turn D into a puzzle language (note that I am not saying your feature is bad, far from it, I am just saying that the syntax you have proposed is very far from being easy to understand from the way it is written). Regardless of what Don has said, here I'd probably like something like a readable @attribute to replace this(this) :-) Bye, bearophile Well, as long as S is the name of the struct, it's essentially what's done in C++ all the time. So, we get S(ref S src) instead of S(const S src) The weird thing here is that you're actually altering the parameter that you passed in, which is normally a major no-no with copy constructors. - Jonathan M Davis
Re: Copy constructors for lazy initialization
Nice. This could also be used to implement unique_ptr(T), with move
semantics.
L.
On 29-5-2010 9:26, Andrei Alexandrescu wrote:
Walter has had a great idea last night: allow classes to define
this(ref S src);
where S is the name of the struct being defined, as an alternative for
this(this);
The result would be a function similar with a C++ copy constructor.
Such an abstraction allows us to perform lazy initialization in a way
that allows the kind of problems associated with non-shared hash tables:
void foo(int[int] x)
{
x[5] = 5;
}
void main()
{
int[int] x;
foo(x);
assert(x[5] == 5); // fails
}
If you change the first line of main() with
int[int] x = [ 42:42 ];
the assert passes.
The idea of the copy constructor is to lazy initialize the source and
the target if the source has null state. That would take care of this
problem and the similar problems for shared state.
There is still a possibility to call a method against an object with
null state. I think that's acceptable, particularly because lazy
initialization saves some state allocation.
What do you think?
Andrei
Re: Copy constructors for lazy initialization
Jonathan M Davis wrote: The weird thing here is that you're actually altering the parameter that you passed in, which is normally a major no-no with copy constructors. Yup. One subtle but important distinction from C++ is that D can omit copy construction completely if the compiler can determine there are no further uses of the source object, and substitute a simple bit copy. This should result in a fundamental performance improvement.
Re: Go has contempt for generics
Jonathan M Davis wrote: Sure, you _can_ use a language without generics (and many other features) and get a lot done, but I'd argue having simplicity as your prime directive tends to lead to an inefficient tool for the programmer. Simplicity should be a goal, but there are times that it should be overridden by other goals. Another way to say that is that if the cost of simplifying the language is pushing the complexity off onto the user code, it's a poor tradeoff.
Re: Go has contempt for generics
On 05/28/2010 08:39 PM, Jonathan M Davis wrote: [snip some good points] So, while some folks seem to want to draw comparisons between Go and D, it sounds like there are definitely things about them which are drastically different, not only in the design, but in the philosophy behind the design. If Go has only a black stare as a response to problems usually tackled by generics in contemporary language, I wouldn't call that a different philosophy, I'd call that a lacuna therein. Andrei
Re: Copy constructors for lazy initialization
On 05/28/2010 09:18 PM, Lionello Lunesu wrote: Nice. This could also be used to implement unique_ptr(T), with move semantics. Yah, a number of interesting idioms spring to life. Andrei
Re: Go has contempt for generics
On 05/28/2010 08:44 PM, bearophile wrote: Andrei Alexandrescu: That has Java 1994 written all over it. Java today can be the most used language, so despite its faults, probably it was good enough. Even if Go has no templates, it has plenty of time to add them five years from now :-) (And in the end templates aren't the only way to design a type-generic language). No language has plenty of time for anything. And the major problem with Go is that its authors seem to not get type genericity at all and try to pretend it doesn't exist. That is a pernicious mistake that will cost that language dearly. (This happened with early Java as well; one hallmark of Java is that it talked out of existence all necessities of modern languages until it adopted them, invariably too late to be properly integrated.) FWIW my impression of Go is veering quickly from well what can you ask? it's unfinished to active dislike. They don't know what they're doing. Andrei
Re: Copy constructors for lazy initialization
On Fri, 28 May 2010 21:26:50 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter has had a great idea last night: allow classes to define
I'm almost positive you meant allow *structs* to define
this(ref S src);
where S is the name of the struct being defined, as an alternative for
this(this);
[snip]
The idea of the copy constructor is to lazy initialize the source and
the target if the source has null state. That would take care of this
problem and the similar problems for shared state.
There is still a possibility to call a method against an object with
null state. I think that's acceptable, particularly because lazy
initialization saves some state allocation.
What do you think?
It is a good effort to solve the problem. The problem I see with such
constructs is inherently the lazy construction. Because you must lazily
construct such a container, every method meant to be called on the struct
must first check and initialize the container if not done already. This
results in an undue burden on the struct author to make sure he covers
every method. The first method he forgets to lazily initialize the struct
results in an obscure bug.
I wonder, would it be possible to go even further? For example, something
like this:
struct S
{
lazy this()
{
// create state
}
}
which would be called if the struct still has not been initialized? lazy
this() should be prepared to accept an already initialized struct, which
should be no problem because most lazily initialized structs always differ
from the .init value.
The compiler could optimize this call out when it can statically determine
that a struct has already been initialized.
This of course, does not cover copy construction, but it would be called
before the copy constructor.
BTW, I'm glad you guys are looking at this problem.
-Steve
Re: CreateThread?
Hello Pavel, I create win32 application. (use dmd 2.046) Exist object Thread in std.thread. Object Thread gives support for garbage collector, but I want to use the function CreateThread. Can I create threads with this function? You can call it (you can call any C function). It should give you a new thread. It might break something else in D (for example: the GC pauses all threads for a collection and that might break) Why do you want to use CreateThread? -- ... IXOYE
Re: Handy templates
Philippe Sigaud wrote: On Thu, May 27, 2010 at 01:00, Simen kjaeraas simen.kja...@gmail.com mailto:simen.kja...@gmail.com wrote: Here's a collection of templates I have created and use often. Some of these may be fit for inclusion in Phobos, others maybe not as much. Please critique, and post your own indispensable snippets. Hey, cool idea ! Do you have a site to put them online? If not, please put them in dsource/scrapple. The one you call Repeat, I call TypeNuple and use it almost on a daily basis. I have a bunch of those there: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/templates.html I'm particularly fond of Compose, TemplateParametersTypeTuple, and TemplateFunArity. Any comme I also have templates acting specifically on typetuples there: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/typetuple2.html Strangely enough, I _have_ uses for things like StaticScan...
noob Q: array out-of-range
Hey...
Compiler is now working as expected! Thank's to a great catch by
Michel Fortin!
A little further down the tutorial D_ A Newbie-Oriented Tutorial,
there's this code:
[code]
import std.stdio;
void main()
{
int[] intArray;
intArray[0] = 42;
intArray[1] = 54;
intArray[2] = 91;
writefln(The lemgth of the intArray is %d.,
intArray.length);
}
[/code]
It compiles with no error or warning - AFAICT. However, it chokes
upon execution with:
dnormandin@ ~/programming/dmd2/code
01:40 pm arrays_in_d
core.exception.rangeer...@arrays_in_d(7): Range violation
I've read and re-read the tutorial content, but it's not jumping out
at me.
--
duke
Re: noob Q: array out-of-range
Duke Normandin wrote:
Hey...
Compiler is now working as expected! Thank's to a great catch by
Michel Fortin!
A little further down the tutorial D_ A Newbie-Oriented Tutorial,
there's this code:
[code]
import std.stdio;
void main()
{
int[] intArray;
intArray[0] = 42;
intArray[1] = 54;
intArray[2] = 91;
writefln(The lemgth of the intArray is %d.,
intArray.length);
}
[/code]
It compiles with no error or warning - AFAICT. However, it chokes
upon execution with:
dnormandin@ ~/programming/dmd2/code
01:40 pm arrays_in_d
core.exception.rangeer...@arrays_in_d(7): Range violation
I've read and re-read the tutorial content, but it's not jumping out
at me.
The array initially has length of zero.
You need to write something like:
intArray = new int[3];
or
intArray.length = 3;
before putting anything into it.
Re: noob Q: array out-of-range
Don: The array initially has length of zero. You need to write something like: intArray = new int[3]; or intArray.length = 3; before putting anything into it. In some languages (Perl? Maybe Lua and PHP) arrays auto-create empty slots as needed, but in many languages you need to tell the language that you want some empty slots before you can put values inside them (this stricter behaviour can probably catch some bugs, and allows to produce faster programs). Another way to add items to a D dynamic array like intArray is to append them at the end, the language runtime takes care of creating new slots as needed: int[] intArray; intArray ~= 1; intArray ~= 2; intArray ~= 3; Bye, bearophile
Re: noob Q: array out-of-range
On Fri, 28 May 2010, bearophile wrote: Don: The array initially has length of zero. You need to write something like: intArray = new int[3]; or intArray.length = 3; before putting anything into it. In some languages (Perl? Maybe Lua and PHP) arrays auto-create empty slots as needed, but in many languages you need to tell the language that you want some empty slots before you can put values inside them (this stricter behaviour can probably catch some bugs, and allows to produce faster programs). Another way to add items to a D dynamic array like intArray is to append them at the end, the language runtime takes care of creating new slots as needed: int[] intArray; intArray ~= 1; intArray ~= 2; intArray ~= 3; Bye, bearophile @Don @bearophile Would you guys visit this URL real quick http://compsci.ca/v3/viewtopic.php?t=9518 This is the site that I'm using to learn D. If you scroll down 3-4 screens full, you'll come to the array topic. Is this tutorial outdated, wrong, or what, because it doesn't deem to sync with what you two fine fellows are telling me about creating dynamic arrays in the D-Language. TIA.. -- duke
Re: noob Q: array out-of-range
Duke Normandin: This is the site that I'm using to learn D. If you scroll down 3-4 screens full, you'll come to the array topic. Is this tutorial outdated, wrong, or what, because it doesn't deem to sync with what you two fine fellows are telling me about creating dynamic arrays in the D-Language. TIA.. That part of that tutorial is not outdated, as far as I know it's just wrong. You can auto-create slots in associative arrays: int[int] aa; aa[0] = 1; aa[1] = 1; aa[2] = 1; Lua language uses associative arrays instead of arrays :-) Bye, bearophile
Re: noob Q: array out-of-range
On Fri, 28 May 2010, bearophile wrote: Duke Normandin: This is the site that I'm using to learn D. If you scroll down 3-4 screens full, you'll come to the array topic. Is this tutorial outdated, wrong, or what, because it doesn't deem to sync with what you two fine fellows are telling me about creating dynamic arrays in the D-Language. TIA.. That part of that tutorial is not outdated, as far as I know it's just wrong. You can auto-create slots in associative arrays: int[int] aa; aa[0] = 1; aa[1] = 1; aa[2] = 1; Lua language uses associative arrays instead of arrays :-) Bye, bearophile So these two paragraphs in the tutorial are flat out wrong? [quote] You should note that I never specified how long the array should be. Instead I simply assigned values to various positions in the array and it just worked. This is an example of a dynamic array. It will grow to whatever size is required. I can determine the size of an array at any time by accessing the array's length property. The length property can also have a value assigned to it to resize the array. [/quote] Maybe the link for this tutorial at: http://www.prowiki.org/wiki4d/wiki.cgi?FirstLanguage should be removed? -- duke
Re: noob Q: array out-of-range
Duke Normandin dukeofp...@ml1.net wrote: So these two paragraphs in the tutorial are flat out wrong? Absolutely. -- Simen
Re: noob Q: array out-of-range
On Sat, 29 May 2010, Simen kjaeraas wrote: Duke Normandin dukeofp...@ml1.net wrote: So these two paragraphs in the tutorial are flat out wrong? Absolutely. Then I'm done with _that_ site - can't trust it! Any chance that you could suggest a good beginner's D tutorial? -- duke
Re: Handy templates
Hello Don, Philippe Sigaud wrote: On Thu, May 27, 2010 at 01:00, Simen kjaeraas simen.kja...@gmail.com mailto:simen.kja...@gmail.com wrote: Here's a collection of templates I have created and use often. Some of these may be fit for inclusion in Phobos, others maybe not as much. Please critique, and post your own indispensable snippets. Hey, cool idea ! Do you have a site to put them online? If not, please put them in dsource/scrapple. If you need access, ping me and I'll get you in. The one you call Repeat, I call TypeNuple and use it almost on a daily basis. I have a bunch of those there: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/templates. html I'm particularly fond of Compose, TemplateParametersTypeTuple, and TemplateFunArity. Any comme I also have templates acting specifically on typetuples there: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/typetuple2 .html Strangely enough, I _have_ uses for things like StaticScan... -- ... IXOYE
Re: noob Q: array out-of-range
Hello Simen, Duke Normandin dukeofp...@ml1.net wrote: So these two paragraphs in the tutorial are flat out wrong? Absolutely. Any idea who owns it so it can get changed? For that matter, who added the link? Being paranoid for the moment (it can be fun sometimes :) that blurb is so wrong that I wonder if it's an attempt to frustrate newbies away from D? -- ... IXOYE
Re: noob Q: array out-of-range
On Fri, 28 May 2010 22:42:32 -0400, Duke Normandin dukeofp...@ml1.net wrote: On Sat, 29 May 2010, Simen kjaeraas wrote: Duke Normandin dukeofp...@ml1.net wrote: So these two paragraphs in the tutorial are flat out wrong? Absolutely. Then I'm done with _that_ site - can't trust it! Any chance that you could suggest a good beginner's D tutorial? It's quite possible that the example code *worked* at some very early version of the D compiler. Nowadays, all arrays are initialized with null as the pointer, guaranteeing that the first time you access array[0], it will segfault. So with the current compilers, that code is *guaranteed* to not work. I speak not from experience, ever since I've started using D it always initializes arrays to null. I just can't imagine that someone would have written such a tutorial without having some experience with D, and without ever having compiled the code. So my logical conclusion is that either 1) at some point, that code did work, 2) the author was so convinced of his D mastery that he didn't bother to try any of his examples, or 3) the page is a blatant attempt to make users not like D. I find 2 unlikely since he specifically mentions how you don't have to initialize arrays. I wonder if someone recalls the feature set of the dmd compiler from July, 2005. -Steve
[Issue 4245] New: Declaring conflicting symbols in single function scope allowed
http://d.puremagic.com/issues/show_bug.cgi?id=4245
Summary: Declaring conflicting symbols in single function scope
allowed
Product: D
Version: 2.041
Platform: x86
OS/Version: All
Status: NEW
Keywords: accepts-invalid, link-failure, patch
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro rsi...@gmail.com 2010-05-28 04:30:37 PDT
---
Created an attachment (id=644)
Patch for dmd svn r502
This code is correctly rejected:
test1.d
void main()
{
{ void foo() {} }
{ void foo() {} }
}
% dmd test1
test1.d(4): Error: declaration foo is already defined in another scope in main
However the following is accepted and link fails due to the name conflict.
test2.d
void main()
{
{ typedefint T = 1; T v; assert(v == 1); }
{ struct T { int a = 2; } T v; assert(v.a == 2); }
{ union T { int a = 3; } T v; assert(v.a == 3); }
{ class T { int a = 4; } T v; assert(v.a == 4); }
{ enum T { a = 5 } T v; assert(v == 5); }
}
% dmd test2
test2.o(.rodata+0x14): multiple definition of `_Dmain1T6__initZ'
test2.o(.rodata+0x10): first defined here
test2.o(.rodata+0x18): multiple definition of `_Dmain1T6__initZ'
test2.o(.rodata+0x10): first defined here
test2.o(.rodata+0x20): multiple definition of `_Dmain1T6__initZ'
test2.o(.rodata+0x10): first defined here
The attached patch fixes the problem by rejecting such cases.
% dmd test2
test2.d(4): Error: declaration T is already defined in another scope in main
test2.d(5): Error: declaration T is already defined in another scope in main
test2.d(6): Error: declaration T is already defined in another scope in main
test2.d(7): Error: declaration T is already defined in another scope in main
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4237] Typedefs of the same name cause initializer conflict
http://d.puremagic.com/issues/show_bug.cgi?id=4237
Shin Fujishiro rsi...@gmail.com changed:
What|Removed |Added
Keywords||patch
Summary|Link error with typedefs of |Typedefs of the same name
|the same name in a function |cause initializer conflict
|scope |
--- Comment #1 from Shin Fujishiro rsi...@gmail.com 2010-05-28 04:51:17 PDT
---
Maybe the example in #0 should be error. I filed a separate bug 4245.
Still the problem exists. As shown in the output example below, the two
distinct typedefs get mangled to the same name. Then the assertion fails due
to the corrupted initial value.
test.d
struct Struct(T) { T value; }
void foo()
{
typedef int Number = 1;
Struct!Number s;
pragma(msg, typeof(s).mangleof);
assert(s.value == 1);
}
void bar()
{
typedef real Number = 2;
Struct!Number s;
pragma(msg, typeof(s).mangleof);
assert(s.value == 2); // Assertion failure
}
void main() { foo(); bar(); }
% dmd -run test
S4test20__T6StructTT6NumberZ6Struct
S4test20__T6StructTT6NumberZ6Struct
core.exception.asserter...@test(14): Assertion failure
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4237] Typedefs of the same name cause initializer conflict
http://d.puremagic.com/issues/show_bug.cgi?id=4237
--- Comment #2 from Shin Fujishiro rsi...@gmail.com 2010-05-28 04:54:49 PDT
---
Here's a trivial patch to dmd svn r502.
--- src/declaration.c
+++ src/declaration.c
@@ -296,6 +296,7 @@ Dsymbol *TypedefDeclaration::syntaxCopy(Dsymbol *s)
void TypedefDeclaration::semantic(Scope *sc)
{
//printf(TypedefDeclaration::semantic(%s) sem = %d\n, toChars(), sem);
+parent = sc-parent;
if (sem == 0)
{ sem = 1;
basetype = basetype-semantic(loc, sc);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4056] Template instantiation with bare parameter not documented
http://d.puremagic.com/issues/show_bug.cgi?id=4056 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-05-28 10:36:31 PDT --- changeset 1564 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4206] type accepted as enum initializer
http://d.puremagic.com/issues/show_bug.cgi?id=4206
--- Comment #2 from Rainer Schuetze r.sagita...@gmx.de 2010-05-28 12:18:05
PDT ---
You're right, it correctly does not compile with dmd 1.056. I must have been
halucinating. Also, enum { var = myint }; causes an error.
The use case that was failing with D2 is
pragma(msg, __traits(compiles, { enum var = myint; }));
and outputs true.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3445] DDoc usually omits attributes (including pure nothrow)
http://d.puremagic.com/issues/show_bug.cgi?id=3445 Don clugd...@yahoo.com.au changed: What|Removed |Added Summary|DDoc usually omits pure |DDoc usually omits |nothrow |attributes (including pure ||nothrow) Severity|normal |critical -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3120] std.process.execv() pass arguments to programm incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=3120
Masahiro Nakagawa repeate...@gmail.com changed:
What|Removed |Added
CC||repeate...@gmail.com
--- Comment #4 from Masahiro Nakagawa repeate...@gmail.com 2010-05-28
13:36:35 PDT ---
This behavior is caused by dmc(I tested on Windows XP).
called.c
-
#include stdio.h
int main(int argc, char* argv[])
{
int i = 0;
for (; i argc; i++)
printf(%s , argv[i]);
}
-
caller.c
-
#include stdlib.h
int main()
{
const char* const argv[] = {a1, a2, a3, NULL};
execv(called.exe, argv);
return 0;
}
-
dmc prints called.exe a2 a3 but gcc prints a1 a2 a3. I think expected
behavior is gcc result(not called.exe arg1 arg2 arg3).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4246] New: Delegate literals passed to variadic templates function incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4246
Summary: Delegate literals passed to variadic templates
function incorrectly
Product: D
Version: future
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P3
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: sandf...@jhu.edu
--- Comment #0 from Rob Jacques sandf...@jhu.edu 2010-05-28 14:17:47 PDT ---
I found this while playing with delegate literals and map. Thankfully, map and
non-variadic templates don't compile with delegate literals, but this example
does:
import std.stdio: writeln;
import std.range;
import std.algorithm;
template bar(fun...) {
auto bar(int[] r) {
return fun[0](r.front);
}
}
void main(string[] args) {
int[] x = [1,2,3,4,5];
int y = 6;
auto dg = (int t){ return t + y; };
auto list = bar!( dg )(x);
auto list2 = bar!( (int t){ return t + y; } )(x);
writeln(list,'\t',list2);
return;
}
This prints out the correct value (7) when a delegate is passed in, but the
delegate literal call results in a random printed number.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4246] Delegate literals passed to variadic templates function incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4246
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2010-05-28 15:09:26 PDT ---
I think this used to work:
import std.algorithm;
void main() {
auto arr = [1, 2, 3];
auto xr1 = map!(a * a)(arr); // OK
auto xr2 = map!((int x){ return x * x; })(arr); // ERR
auto xr3 = map!((x){ return x * x; })(arr); // ERR
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3887] ddoc does not replicate @property to documentation
http://d.puremagic.com/issues/show_bug.cgi?id=3887 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2010-05-28 15:17:13 PDT --- Yep, I guess other properties also don't show up. *** This issue has been marked as a duplicate of issue 3445 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3445] DDoc usually omits attributes (including pure nothrow)
http://d.puremagic.com/issues/show_bug.cgi?id=3445 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2010-05-28 15:17:13 PDT --- *** Issue 3887 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3445] DDoc usually omits attributes (including pure nothrow)
http://d.puremagic.com/issues/show_bug.cgi?id=3445 --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2010-05-28 15:17:43 PDT --- From 3887, @property also doesn't show up. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4247] New: Cannot create default-constructed struct on heap when constructor is defined
http://d.puremagic.com/issues/show_bug.cgi?id=4247
Summary: Cannot create default-constructed struct on heap when
constructor is defined
Product: D
Version: 2.041
Platform: Other
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer schvei...@yahoo.com 2010-05-28
15:55:49 PDT ---
If I want a struct on the heap, I do this:
struct S
{
}
auto s = new S;
But if I give S a constructor:
struct S
{
this(int n) {}
}
auto s = new S;
dmd complains:
Error: constructor S.this (int n) is not callable using argument types ()
So I do this:
struct S
{
this() {}
this(int n) {}
}
but dmd now complains:
Error: constructor S.this default constructor not allowed for structs
So the auto s = new S is no longer usable. However, I can easily declare a
struct S on the stack, or create a new array of S. In fact, you can do:
auto s = (new S[1])[0];
and achieve the desired effect, but this is oh so ugly.
Bottom line, if I can construct a struct on the stack, I should be able to
identically construct it on the heap.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1087] scope(exit) is ignored if preceded by a label
http://d.puremagic.com/issues/show_bug.cgi?id=1087 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||DUPLICATE --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-05-28 21:38:56 PDT --- *** This issue has been marked as a duplicate of issue 1894 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4242] ICE(module.c): importing a module with same name as package
http://d.puremagic.com/issues/show_bug.cgi?id=4242 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-05-28 22:32:38 PDT --- http://www.dsource.org/projects/dmd/changeset/504 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1513] try/catch/finally misbehavior on windows
http://d.puremagic.com/issues/show_bug.cgi?id=1513 --- Comment #4 from Brad Roberts bra...@puremagic.com 2010-05-28 22:51:25 PDT --- I figured it'd been ages and maybe something had changed to maybe fix this bug.. nope: dmd 1.061 on windows: Error: ex 2 throw ex1 throw ex2 dmd 1.061 on linux: throw ex1 throw ex2 throw ex3 Error: ex 3 dmd 2.046 on windows: throw ex1 throw ex2 object.Exception: ex 2 dmd 2.047 (close to svn tip) on linux: throw ex1 throw ex2 throw ex3 object.Exception: ex 3 --- cut the stack trace --- So.. still different. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
