Re: Operator overloading, structs
bearophile wrote: - In #2 D doesn't have a standard method that returns true/false. In Python2.6 such method is named __nonzero__ and in python3 it's named __bool__.<< No one has commented about that, but I think that having a way to overload cast(bool)foo is important. I use it in Python and I have shown why and how it can be used in D too. It's an easy thing to do and I think it's safe. It's definitely required for completeness. In C++ there's a hack to do it safely (you return a pointer to a private member class). Still, I wonder if D could simply do something like defining that for classes: if (x) is always transformed into if ( x!=0 ) if (!x) is always transformed into if ( x==0 ) Don: D1 has opCast, but here I think not even a[cast(long)i] works, because BigInt doesn't define it yet. When a big int can't be converted to long, it can throw an exception. Yes, that's not a bad idea. But eventually an implicit cast will be better (even if a bit less safe) in D2. On second thoughts, y = x.toLong or y = to!(long)(x) is probably better. Casts are evil, implicit casts even more so. Not toString(), though. You MUST be able to specify if you want leading zeros, and if you want hex or decimal. toString() is for the default case, when you just want the decimal number with no leading zeros. Then you can add other methods to output hex and all you want. (In what situations do you want to print leading zeros of a big multiprecision integral value? I have never faced such need so far). BigFloat, for example.
Re: Unique as a transitive type?
Jason House wrote: Sean Kelly Wrote: Jason House wrote: Andrei has stated previously that unique was left out of the type system because it added little value to the const system. Now that shared and multithreading are here, unique has more value. I have two basic questions: 1. What would make unique difficult to add? Move semantics. Just passing a unique value type to a function, a copy is performed. Why would copying occur? Can't a function simply pass it by reference and then zero out that register when done? Technically, yes. I meant more from a language standpoint. A copy theoretically occurs when returning a value from a function as well.
Re: Unique as a transitive type?
Sean Kelly Wrote: > Jason House wrote: > > Andrei has stated previously that unique was left out of the type system > > because it added little value to the const system. Now that shared and > > multithreading are here, unique has more value. > > > > I have two basic questions: > > > > 1. What would make unique difficult to add? > > Move semantics. Just passing a unique value type to a function, a copy > is performed. Why would copying occur? Can't a function simply pass it by reference and then zero out that register when done? > > 2. What benefits do you forsee? > > Message passing could be done without needless copying and with a > reasonable degree of safety. I've done this before in C++ by storing > the reference in a modified shared_ptr (so it can live in containers), > then asserting is_unique() and transferring the reference to an auto_ptr > when passing into the message. Kind of messy, but it works well enough.
Re: Unique as a transitive type?
Jason House wrote: Andrei has stated previously that unique was left out of the type system because it added little value to the const system. Now that shared and multithreading are here, unique has more value. I have two basic questions: 1. What would make unique difficult to add? Move semantics. Just passing a unique value type to a function, a copy is performed. 2. What benefits do you forsee? Message passing could be done without needless copying and with a reasonable degree of safety. I've done this before in C++ by storing the reference in a modified shared_ptr (so it can live in containers), then asserting is_unique() and transferring the reference to an auto_ptr when passing into the message. Kind of messy, but it works well enough.
Re: Unique as a transitive type?
On Mon, 01 Jun 2009 19:16:55 -0400, Jason House wrote: Andrei has stated previously that unique was left out of the type system because it added little value to the const system. Now that shared and multithreading are here, unique has more value. I have two basic questions: 1. What would make unique difficult to add? 2. What benefits do you forsee? Here are my thoughts: 1) Escape analysis - construction of unique objects must be careful with how they manipulate their members. This would require scope parameters (AKA lent in Bartosz's blog/literature). After construction, it may also be necessary to update the manipulate the unique object while preserving its uniqueness. Personally, I like the idea of scope by default, but I'm probably in the minority. 2) Plugs a gaping hole in the type system. Even with shared added, I had a moderate multi-threaded code base compile and run without use of shared or casting. That boiled down to an inability to start threads without (silently) subverting the type system. It's also possible to optimize operations on unique data in ways that one can't do when a rogue write reference might exist somewhere. That's not the same as invariant, but it's similar. Unique can be implicitly cast to scope invariant. 1) Well, the difficulty I see, is that you can't just add unique. When I think of unique, I generally think of it as being shallow - i.e. that object is unique, but it can contain references to non-unique objects (not-transitive). Though this makes construction, etc, easier, there are times you'd like to have non-unique members which are protected by the uniqueness of the parent. This adds a 'owned' type, which starts to run into Escape analysis issues. Then there's ref unique, which is an odd duck: first the unique is moved into the function, and then on scope(exit) it is moved back out. This subtly comes into play with things like tasks/futures. Of course, there's also 'lent', which allows unique to be used with a wider range of functions. 2) To me, unique is all about performance. Shared can do all the same things, it just cost's taking a thin-lock to do so, which is pretty cheap. Having it as a type (instead of its current form as library template) does have some integration benefits with the lent system, but that's about it. BTW, shared isn't implemented yet (beyond basic keyword recognition)
Re: Unique as a transitive type?
In the short time I was at the Kahili coffeehouse summit I heard Walter say more than once that he was troubled by the idea of more transitive construction types because he was afraid of the combinatorial explosion that would occur. And that was just adding 'unique'. Bartosz was trying to talk him into 'unique' and 'lent'. I don't know if Bartosz and Andrei and Walter came to any agreement -- they seemed to be in three mutually exclusive frames of mind at the start anyway. >From my knothole I think unique and lent would be positive additions, even if >it does offend Walter's finer sensibilities! Paul Jason House Wrote: > Andrei has stated previously that unique was left out of the type system > because it added little value to the const system. Now that shared and > multithreading are here, unique has more value. > > I have two basic questions: > > 1. What would make unique difficult to add? > > 2. What benefits do you forsee? > > > Here are my thoughts: > 1) Escape analysis - construction of unique objects must be careful with how > they manipulate their members. This would require scope parameters (AKA lent > in Bartosz's blog/literature). After construction, it may also be necessary > to update the manipulate the unique object while preserving its uniqueness. > Personally, I like the idea of scope by default, but I'm probably in the > minority. > > 2) Plugs a gaping hole in the type system. Even with shared added, I had a > moderate multi-threaded code base compile and run without use of shared or > casting. That boiled down to an inability to start threads without (silently) > subverting the type system. > It's also possible to optimize operations on unique data in ways that one > can't do when a rogue write reference might exist somewhere. That's not the > same as invariant, but it's similar. Unique can be implicitly cast to scope > invariant.
Re: Operator overloading, structs
>> - In #2 D doesn't have a standard method that returns true/false. In >> Python2.6 such method is named __nonzero__ and in python3 it's named >> __bool__.<< No one has commented about that, but I think that having a way to overload cast(bool)foo is important. I use it in Python and I have shown why and how it can be used in D too. It's an easy thing to do and I think it's safe. Don: > > D1 has opCast, but here I think not even a[cast(long)i] works, because > > BigInt doesn't define it yet. When a big int can't be converted to long, it > > can throw an exception. > > Yes, that's not a bad idea. But eventually an implicit cast will be better (even if a bit less safe) in D2. > Not toString(), though. You MUST be able to specify if you want leading > zeros, and if you want hex or decimal. toString() is for the default case, when you just want the decimal number with no leading zeros. Then you can add other methods to output hex and all you want. (In what situations do you want to print leading zeros of a big multiprecision integral value? I have never faced such need so far). > But I hate toString() so much, I'm _never_ going to support it. It's an > OMDB (over my dead body). Sorry. I have patched a copy of the bigint module to add the toString method. I'll keep using such patch for my programs. I want you well alive and happy too. > Fixed in Tango SVN 4717. Thank you. Bye, bearophile
Re: Operator overloading, structs
bearophile wrote:
This post is mostly about D2 operator overloading in general, but I also talk
about problems in the API of Tango BigInts.
A small program that use multiprecision integers of Tango:
import tango.stdc.stdio: printf;
import tango.math.BigInt: bint = BigInt;
void main() {
bint i = 1; // #1
if (i) // #2
i++;
auto a = [10, 20, 30, 40];
printf("%d\n", a[i]); // #3
}
If you replace BigInt with int that program works.
With bigInteger it doesn't work, because I think:
- In #1 it doesn't call static opCall.
Works for me with int. I've fixed BigInt so that it now works with long
as well.
- In #2 D doesn't have a standard method that returns true/false. In Python2.6
such method is named __nonzero__ and in python3 it's named __bool__.
- In #3 there's no implicit cast to int.
I think that improving such D2 operator overloading is very good, it allows to
use BigInts, SafeInts, Complex, etc, in a quite more transparent way, allowing
very similar code to work with native and user defined types.
---
Regarding specifically BigInt:
D1 has opCast, but here I think not even a[cast(long)i] works, because BigInt
doesn't define it yet. When a big int can't be converted to long, it can throw
an exception.
Yes, that's not a bad idea.
Until a more efficient solution is found, I think BigInts must have a toString
too. In most situations you don't print such numbers, you do lot of
computations with them and then you finally print some of them. So often the
time spent printing them is not much).
Not toString(), though. You MUST be able to specify if you want leading
zeros, and if you want hex or decimal. I just (a) haven't got around to
it; and (b) haven't been sure about the interface should be.
But I hate toString() so much, I'm _never_ going to support it. It's an
OMDB (over my dead body). Sorry.
I think BigInt also may enjoy a lot methods like: int opEquals(int y), etc.
Ouch! That's a simple omission.
Fixed in Tango SVN 4717.
Unique as a transitive type?
Andrei has stated previously that unique was left out of the type system because it added little value to the const system. Now that shared and multithreading are here, unique has more value. I have two basic questions: 1. What would make unique difficult to add? 2. What benefits do you forsee? Here are my thoughts: 1) Escape analysis - construction of unique objects must be careful with how they manipulate their members. This would require scope parameters (AKA lent in Bartosz's blog/literature). After construction, it may also be necessary to update the manipulate the unique object while preserving its uniqueness. Personally, I like the idea of scope by default, but I'm probably in the minority. 2) Plugs a gaping hole in the type system. Even with shared added, I had a moderate multi-threaded code base compile and run without use of shared or casting. That boiled down to an inability to start threads without (silently) subverting the type system. It's also possible to optimize operations on unique data in ways that one can't do when a rogue write reference might exist somewhere. That's not the same as invariant, but it's similar. Unique can be implicitly cast to scope invariant.
Re: Why are void[] contents marked as having pointers?
Vladimir Panteleev wrote: On Mon, 01 Jun 2009 14:10:57 +0300, Christopher Wright wrote: Vladimir Panteleev wrote: On Mon, 01 Jun 2009 05:28:39 +0300, Christopher Wright wrote: Vladimir Panteleev wrote: std.boxer is actually a valid counter-example for my post. The specific fix is simple: replace the void[] with void*[]. The generic "fix" is just to add a line to http://www.digitalmars.com/d/garbage.html adding that hiding your only reference in a void[] results in undefined behavior. I don't think this should be an inconvenience to any projects? What do you use for "may contain unaligned pointers"? Sorry, what do you mean? I don't understand why such a type is needed? Implementing support for scanning memory ranges for unaligned pointers will slow down the GC even more. Because you can have a struct with align(1) that contains pointers. Then these pointers can be unaligned. Then an array of those structs cast to a void*[] would contain pointers, but as an optimization, the GC would consider the pointers in this array aligned because you tell it they are. The GC will not "see" unaligned pointers, regardless if they're in a struct or void[] array. The GC doesn't know the type of the data it's scanning - it just knows if it might contain pointers or it definitely doesn't contain pointers. Okay, so currently the GC doesn't do anything interesting with its type information. You're suggesting that that be enforced and codified.
Re: Source control for all dmd source (Git propaganda =)
On Mon, 01 Jun 2009 18:20:49 +0300, Jérôme M. Berger wrote: > [snip] Since no one posted this link in this thread yet: http://whygitisbetterthanx.com/ -- Best regards, Vladimir mailto:thecybersha...@gmail.com
Re: Source control for all dmd source (Git propaganda =)
"Jérôme M. Berger", el 1 de junio a las 19:55 me escribiste: > Daniel Keep wrote: > >Jérôme M. Berger wrote: > >>Leandro Lucarella wrote: > >>>Anyways, my point was, putting DMDFE in a SCM would be great, even when > >>>it's svn. For me the ideal would be Git, Mercurial or other distributed > >>>SCM would be nice, but even svn is better than we have now =) > >>> > >>Oh, I agree. However, IMO git is a poor choice. Mercurial, Bazaar or > >>svn would be better. > >After having used both git and svn, I'll have to VERY strongly disagree > >with that last part. I'd imagine that *any* half-way sane DVCS would be > >better than svn. > >As for the others, you don't provide any objective reasons for WHY > >they're better than git. > Well, the reason *I* don't use git is that at the time I started using > a DVCS, > it didn't run at all on Windows (some people reported partial success with > cygwin but that was all). Even if support has improved, it still seems to me > like Windows is a second rate citizen in the git world, and this leads me to > worry about how git handles the idiosyncrasies of Windows. Plus, my > experience > with other cygwin/msys based projects leave me worried about git's speed on > Windows (although I haven't tested it). Why don't you test it and stop talking about what you think it's going on and start talking about what's *really* going on. It doesn't seems very fair to discard something just because you have the feeling that it wouldn't work well (specially when other people use it and say it works well). Anyway, I insist that the main point is having DMDFE in a SCM. If Walter feels comfortable with svn *now*, I think it should be svn *now*. I prefer some no-ideal SCM *now* than the ideal SCM *in a distant future*. We can always migrate the repo to something else when the time is right... > Moreover, everything I've read on the web seems to indicate that git is > difficult to use if you want to do more than add/commit/update. Mercurial is > *very* easy to both setup and use on windows as well as linux. I'm less > familiar > with Bazaar, but from what I've seen it's very similar to Mercurial. Again "I've read". =) I'm telling you, git is easy, it just a little harder to get used to it, but it's so much better when you do... > Finally, no matter how good it is, TortoiseGIT is not enough (in the > same way > that TortoiseCVS, TortoiseSVN and TortoiseHg are not enough). You need good > command-line support so that you can access it easily from custom tools (for > example to generate releases automatically). You have a good command-line support. > On a side note, we have to ask ourselves: is a DSCM really needed for > D? So > long as there are only a few developers, a centralized system might be enough > (in which case svn becomes the only real choice). I think it's not *needed*, as a SCM is not *needed* either. Having one (SCM) just would make things easier (and might encourage developers to hack DMDFE, as following the changes in a repo might give you a better insight about how is written and maybe people can spot bugs too). Having a DSCM would make things easier for people that integrates DMDFE in other projects than DMD. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: Source control for all dmd source
Reply to hasen, BCS wrote: It seems you don't like GUIs. Obviously, others doesn't agree with you. Now, git comes with its own set of concepts, that are completely different from svn. "checkout" in git has nothing to do with "checkout" in svn. What's a branch? what's merging? where/how does merging happen? There's just no way you could work with git without knowing about all of this. It's not complicated or anything, but you have to learn it. So, when you learn to use it from the command line, then what's the point of the gui? See, because I come from windows, GUI to me means that I don't have to learn anything; that I can just sail through it and it will somehow work out on its own. That's why GUIs that just offer buttons that map directly to CLI commands are confusing. OK I see where you are coming from and why we are seeing things so differently. To me, a GUI is not about "It just works" kinds of things. That's just good design and can be had (with more design work) in a CLI as well. To me, a GUI is about having more dimensions of input, more simultaneous channels of communication. I can see many different bits of information in a non linear way. I can have many contexts available at the same time. I can access many action from the same point. I'd much rather select from a set of files with check boxes than by typing in file names. Imagine a file explorer where you have to right click a directory and choose "cd" from the menu. and then it will cd into that directory, but not show you the files inside it, instead it shows a blank, and then you right click somewhere in that empty area and choose "ls". better yet, "ls" would bring a sub-menu, where one of the choices is "-al", or maybe just be smart and write it out as "all", to confuse the user, and make him think "Oh, so it usually lists the first 10 files only unless I choose all? To conserve screen space maybe?" There is a big difference; with Git/SVN many of the commands have side effect and many of the others take a bit of time and space to operate on. The way I've got SVN/Git set up the most useful information (file status) is shown right up front as icon overlays. I don't /want/ any more information that that because the next most useful bits (diffs for instance) wouldn't fit on any screen I could use.
Re: Source control for all dmd source
hasen wrote: BCS wrote: It seems you don't like GUIs. Obviously, others doesn't agree with you. Actually no, I don't hate guis, but I come from windows, and in the world of windows, you get used to expect programs to work without you having to read manuals. For example, I used to play with the Half-Life SDK, and while I had to read some tutorials about how to download it and set it up, etc, the rest just worked in an out-of-the-box kind of way. I never had to read any manuals for Visual Studio, it just kinda worked, the expectations you have about it turn out to be true most of the time, and if they're not, you can sort if work it out in your head and discover how it works. With something like svn, you can't have any expectation; you just have to learn it through the manual/tutorials. What the hell is a commit? what's a log? what's revert? etc etc. There's just no other way around it other than to read and learn all these concepts. And just what the hell is a "working directory"? That thing kept confusing the hell out of me. Now, git comes with its own set of concepts, that are completely different from svn. "checkout" in git has nothing to do with "checkout" in svn. What's a branch? what's merging? where/how does merging happen? There's just no way you could work with git without knowing about all of this. It's not complicated or anything, but you have to learn it. So, when you learn to use it from the command line, then what's the point of the gui? See, because I come from windows, GUI to me means that I don't have to learn anything; that I can just sail through it and it will somehow work out on its own. That's why GUIs that just offer buttons that map directly to CLI commands are confusing. I don't see TortoiseSVN as a one-to-one mapping between buttons and command-line actions. For example when you select SVN Commit you can add files from there, ignore files, revert changes, see differences. So it basically unified all the tools in a comfortable way. It also lets you see which files are now and gives you the option to add them. How do you do that with the command line?
Re: Source control for all dmd source
BCS wrote: It seems you don't like GUIs. Obviously, others doesn't agree with you. Actually no, I don't hate guis, but I come from windows, and in the world of windows, you get used to expect programs to work without you having to read manuals. For example, I used to play with the Half-Life SDK, and while I had to read some tutorials about how to download it and set it up, etc, the rest just worked in an out-of-the-box kind of way. I never had to read any manuals for Visual Studio, it just kinda worked, the expectations you have about it turn out to be true most of the time, and if they're not, you can sort if work it out in your head and discover how it works. With something like svn, you can't have any expectation; you just have to learn it through the manual/tutorials. What the hell is a commit? what's a log? what's revert? etc etc. There's just no other way around it other than to read and learn all these concepts. And just what the hell is a "working directory"? That thing kept confusing the hell out of me. Now, git comes with its own set of concepts, that are completely different from svn. "checkout" in git has nothing to do with "checkout" in svn. What's a branch? what's merging? where/how does merging happen? There's just no way you could work with git without knowing about all of this. It's not complicated or anything, but you have to learn it. So, when you learn to use it from the command line, then what's the point of the gui? See, because I come from windows, GUI to me means that I don't have to learn anything; that I can just sail through it and it will somehow work out on its own. That's why GUIs that just offer buttons that map directly to CLI commands are confusing. Imagine a file explorer where you have to right click a directory and choose "cd" from the menu. and then it will cd into that directory, but not show you the files inside it, instead it shows a blank, and then you right click somewhere in that empty area and choose "ls". better yet, "ls" would bring a sub-menu, where one of the choices is "-al", or maybe just be smart and write it out as "all", to confuse the user, and make him think "Oh, so it usually lists the first 10 files only unless I choose all? To conserve screen space maybe?"
Re: Source control for all dmd source
Reply to hasen, Daniel Keep wrote: hasen wrote: ... Wow, tortoisegit? Seems so bloated, look at those screen shots, it's so confusing! Wow, git cli? Seems so bloated, look at all those commands, it's so confusing! It *is* confusing, it doesn't claim to be intuitive, it's aimed for developers, they're supposed to read tutorials/man pages to know how it works. No they're not. The difference between a technical and non-technical user is that the technical one *will* read manual if they have to. If there is any other choice, no program should *ever* be designed so that the user is forced to read the manual. Whenever possible, no matter the user, the UI should be intuitive. (OK I'll grant that in the technical user case some intuitiveness can be traded for speed of use but in this case I don't think their is a conflict) Providing a gui that maps a "pull" button to a pull command is confusing because GUI's are supposed to be "discoverable" and "intuitive". Both GUIs and CLIs are. No wonder I never knew how to properly use svn, I was so dependant on those GUIs, that I never knew what was going on under the surface. Odd, I started using SVN via a GUI and now I rarely if ever use the CLI and I never had a problem figuring out what was going on under the surface. At least for me, the only sensible way to use svn is through the command line. GUIs for svn and git are confusing because well, you're not exactly sure what they're doing. That is not true. I am sure of what my SVN GUI is doing. As for Git, I have yet to have any problem with it that were cause by it hiding what it was doing (the only problem I've had is it not even showing some functionality) Actually, if you look at them, the dialogs are all just GUI versions of the various git tools themselves. So if you really find those confusing, I can only assume you find Git itself confusing. Look at this and tell me it's not confusing: http://www.jensroesner.de/wgetgui/wgetgui.png Is that from TortoiusGit? IMO it's wrong to just put the same command-line commands on the right-click menu, and call that a gui. Yes, because heaven forbid anyone makes our lives as developers easier. After all, no developer should EVER use a simplified interface when what they SHOULD be doing is memorising every command and all of its switches. The heresy! Well, if it makes your life easier, good for you. It does. The humble git-gui is much better. Integrating those commands into the shell itself so that only the commands that make sense in context are shown, and actually tell the user what they're going to do is much better. Incidentally, I use both. TortoiseGit is great for anything of relative complexity as it actually helps you do it correctly (it took me a while to work out how to properly apply patch sets without it). What's more, it also helps you learn how to use git without constantly screwing up. I think if you don't know what you're doing you'll screw up anyway. I used to use SmartSVN, TortoiseSVN, and probably some other GUIs, and every so often I would screw something up and have no idea how to fix it. Yup, I known what you are talking about. But what does that have to do with GUIs? Why? because the GUI made me feel comfortable using svn without really knowing what the hell was going on. I wouldn't feel very comfortable using svn or git without knowing what it's doing regardless of the UI. It seems you don't like GUIs. Obviously, others doesn't agree with you.
Re: Source control for all dmd source
Reply to hasen, IMO it's wrong to just put the same command-line commands on the right-click menu, and call that a gui. I like exactly that kind of approach, it gives you the full power of the command line without having to keep a command shell(s) around in the correct directory(s). All the advantages of both the CLI word and the GUI world. OTOH that is all theoretical as I just installed it about a week ago and have already discovered that several key features are unavailable from it (not hooked up it would seem).
Re: Source control for all dmd source (Git propaganda =)
Daniel Keep wrote: Jérôme M. Berger wrote: Leandro Lucarella wrote: Anyways, my point was, putting DMDFE in a SCM would be great, even when it's svn. For me the ideal would be Git, Mercurial or other distributed SCM would be nice, but even svn is better than we have now =) Oh, I agree. However, IMO git is a poor choice. Mercurial, Bazaar or svn would be better. After having used both git and svn, I'll have to VERY strongly disagree with that last part. I'd imagine that *any* half-way sane DVCS would be better than svn. As for the others, you don't provide any objective reasons for WHY they're better than git. Well, the reason *I* don't use git is that at the time I started using a DVCS, it didn't run at all on Windows (some people reported partial success with cygwin but that was all). Even if support has improved, it still seems to me like Windows is a second rate citizen in the git world, and this leads me to worry about how git handles the idiosyncrasies of Windows. Plus, my experience with other cygwin/msys based projects leave me worried about git's speed on Windows (although I haven't tested it). Moreover, everything I've read on the web seems to indicate that git is difficult to use if you want to do more than add/commit/update. Mercurial is *very* easy to both setup and use on windows as well as linux. I'm less familiar with Bazaar, but from what I've seen it's very similar to Mercurial. Finally, no matter how good it is, TortoiseGIT is not enough (in the same way that TortoiseCVS, TortoiseSVN and TortoiseHg are not enough). You need good command-line support so that you can access it easily from custom tools (for example to generate releases automatically). On a side note, we have to ask ourselves: is a DSCM really needed for D? So long as there are only a few developers, a centralized system might be enough (in which case svn becomes the only real choice). Jerome PS: http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Source control for all dmd source (Git propaganda =)
Jérôme M. Berger wrote: > Leandro Lucarella wrote: >> Anyways, my point was, putting DMDFE in a SCM would be great, even when >> it's svn. For me the ideal would be Git, Mercurial or other distributed >> SCM would be nice, but even svn is better than we have now =) >> > Oh, I agree. However, IMO git is a poor choice. Mercurial, Bazaar or > svn would be better. After having used both git and svn, I'll have to VERY strongly disagree with that last part. I'd imagine that *any* half-way sane DVCS would be better than svn. As for the others, you don't provide any objective reasons for WHY they're better than git. > For some interesting reading: > > - Here are the reasons that pushed Python to use Mercurial (includes the > reasons for the change from centralized to distributed SCM and the > reasons for choosing Mercurial): http://www.python.org/dev/peps/pep-0374/ The weakness of Git's support for Windows relative to the others is probably a valid point; I haven't used the other two. It's worth noting, however, that I *do* use Git in both Windows and Linux and I've only felt disadvantaged on Windows in one specific case: the Windows build lacks svn integration. [1] Another reason was "it's not Python," which is obviously irrelevant in this case. The only other reason was popularity. The table doesn't really specify WHY the others were more popular. This could be either that mercurial is much easier to use, or the majority of Python devs prefer typing two characters instead of three. :P > - Here's the same for Mozilla: > http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html That's over three years old and the only reason stated is that it is "lacking Win32 support" which is obviously no longer true. [1] Apparently this is because the svn integration depends on the perl svn bindings, and no one can get both perl AND perl-svn compiling with msys.
Re: Source control for all dmd source (Git propaganda =)
Jérôme M. Berger wrote: - Here's the same for Mozilla: http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html From the article: While they've made recent progress, Git was lacking in Win32 support and it was unclear that this would ever change and if it did change, it was unclear that Git-on-Win32 would ever become something more than a second-class citizen. As good, performant Win32 (and Mac and Linux) is a hard-requirement, Git lost in early Kombat rounds. This is unfortunate because (as we would soon find out), lots of issues with the other systems did "just work" in Git. git's Win32 support via TortoiseGit is nearly as good as SVN's now, so I can't see that being an issue here. So I'd say Git is a great choice for the DMDFE.
Re: Source control for all dmd source (Git propaganda =)
Leandro Lucarella wrote: Anyways, my point was, putting DMDFE in a SCM would be great, even when it's svn. For me the ideal would be Git, Mercurial or other distributed SCM would be nice, but even svn is better than we have now =) Oh, I agree. However, IMO git is a poor choice. Mercurial, Bazaar or svn would be better. For some interesting reading: - Here are the reasons that pushed Python to use Mercurial (includes the reasons for the change from centralized to distributed SCM and the reasons for choosing Mercurial): http://www.python.org/dev/peps/pep-0374/ - Here's the same for Mozilla: http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Source control for all dmd source (Git propaganda =)
Leandro Lucarella wrote: Anyways, my point was, putting DMDFE in a SCM would be great, even when it's svn. For me the ideal would be Git, Mercurial or other distributed SCM would be nice, but even svn is better than we have now =) Even under svn, we can track it with git-svn
Re: Source control for all dmd source
Leandro Lucarella wrote: "Jérôme M. Berger", el 1 de junio a las 12:23 me escribiste: Daniel Keep wrote: Incidentally, I use both. TortoiseGit is great for anything of relative complexity as it actually helps you do it correctly (it took me a while to work out how to properly apply patch sets without it). hg unbundle patchset Sorry, couldn't resist ;) git am mailbox Sorry, me either ;) Well, *I* am not the one who said it was difficult to find out with git ;) Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: forward ranges must offer a save() function
On Sat, 30 May 2009 13:18:06 -0400, Andrei Alexandrescu
wrote:
If we want to allow people to create ranges that are classes (as opposed
to structs) the requirement for a save() function is a must. This is
because copying class ranges with
Range copy = original;
only creates a new alias for original; the two share the same state.
So this solves our forward vs. input ranges dilemma quite nicely: the
save() function at the same time allows distinction between the two
(input ranges don't define a save() function) and also allows ranges to
be implemented as classes as well as structs.
To summarize:
Input ranges: empty front popFront
Forward ranges: + save
Bidir ranges: + back popBack
Random-access ranges: + opIndex opIndexAssign
The disadvantage is that all non-input ranges must define save(), which
is a trivial functions in most cases:
Range save() { return this; }
I have two questions that came to mind:
1. What is the use case for classes as ranges? I can't think of one.
With structs, you can control the aliasing behavior when it is copied, so
the issue is less critical.
2. Even if there is a use case, why put the band-aid on the ranges that
aren't affected? That is, why affect all ranges except input ranges when
input ranges are the issue? Even if this does work, you are going to have
mistakes where you copy the range instead of calling .save, which will
compile successfully. Since you have to special case it, why not just put
a flag in the non-copyable input ranges? Like an enum noCopy = true; or
something. Then you can special case those and have them fail to compile
when they don't support the algo. For classes, you wouldn't need to do
this, because they are by default reference types, and this can be
statically checked.
The point is, make the frequent usage easy, and the one-time range design
require the careful usage.
-Steve
Re: Source control for all dmd source (Git propaganda =)
Anyways, my point was, putting DMDFE in a SCM would be great, even when it's svn. For me the ideal would be Git, Mercurial or other distributed SCM would be nice, but even svn is better than we have now =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: Source control for all dmd source
"Jérôme M. Berger", el 1 de junio a las 12:23 me escribiste: > Daniel Keep wrote: > >Incidentally, I use both. TortoiseGit is great for anything of relative > >complexity as it actually helps you do it correctly (it took me a while > >to work out how to properly apply patch sets without it). > hg unbundle patchset > > Sorry, couldn't resist ;) git am mailbox Sorry, me either ;) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: Why are void[] contents marked as having pointers?
On Mon, 01 Jun 2009 02:18:46 +0300, Andrei Alexandrescu
wrote:
> Vladimir Panteleev wrote:
>> On Mon, 01 Jun 2009 00:00:45 +0300, Andrei Alexandrescu
>> wrote:
>>
>>> const(ubyte)[] getRepresentation(T)(T[] data)
>>> {
>>> return cast(typeof(return)) data;
>>> }
>> This is functionally equivalent to (forgive the D1):
>> ubyte[] getRepresentation(void[] data)
>> {
>> return cast(ubyte[]) data;
>> }
>> Since no allocation is done in this case, the use of void[] is safe,
>> and it doesn't instantiate a version of the function for every type you
>> call it with. I remarked about this in my other reply.
>>
Which is why I wrote "forgive the D1" :)
I've yet to switch to D2, but it's obvious that the const should be there to
ensure safety.
--
Best regards,
Vladimir mailto:thecybersha...@gmail.com
Re: Why are void[] contents marked as having pointers?
On Mon, 01 Jun 2009 14:10:57 +0300, Christopher Wright wrote: > Vladimir Panteleev wrote: >> On Mon, 01 Jun 2009 05:28:39 +0300, Christopher Wright >> wrote: >> >>> Vladimir Panteleev wrote: std.boxer is actually a valid counter-example for my post. The specific fix is simple: replace the void[] with void*[]. The generic "fix" is just to add a line to http://www.digitalmars.com/d/garbage.html adding that hiding your only reference in a void[] results in undefined behavior. I don't think this should be an inconvenience to any projects? >>> What do you use for "may contain unaligned pointers"? >> Sorry, what do you mean? I don't understand why such a type is needed? >> Implementing support for scanning memory ranges for unaligned pointers >> will slow down the GC even more. > > Because you can have a struct with align(1) that contains pointers. Then > these pointers can be unaligned. Then an array of those structs cast to > a void*[] would contain pointers, but as an optimization, the GC would > consider the pointers in this array aligned because you tell it they are. The GC will not "see" unaligned pointers, regardless if they're in a struct or void[] array. The GC doesn't know the type of the data it's scanning - it just knows if it might contain pointers or it definitely doesn't contain pointers. -- Best regards, Vladimir mailto:thecybersha...@gmail.com
Re: Why are void[] contents marked as having pointers?
Vladimir Panteleev wrote: On Mon, 01 Jun 2009 05:28:39 +0300, Christopher Wright wrote: Vladimir Panteleev wrote: std.boxer is actually a valid counter-example for my post. The specific fix is simple: replace the void[] with void*[]. The generic "fix" is just to add a line to http://www.digitalmars.com/d/garbage.html adding that hiding your only reference in a void[] results in undefined behavior. I don't think this should be an inconvenience to any projects? What do you use for "may contain unaligned pointers"? Sorry, what do you mean? I don't understand why such a type is needed? Implementing support for scanning memory ranges for unaligned pointers will slow down the GC even more. Because you can have a struct with align(1) that contains pointers. Then these pointers can be unaligned. Then an array of those structs cast to a void*[] would contain pointers, but as an optimization, the GC would consider the pointers in this array aligned because you tell it they are.
Re: Source control for all dmd source
Daniel Keep wrote: Incidentally, I use both. TortoiseGit is great for anything of relative complexity as it actually helps you do it correctly (it took me a while to work out how to properly apply patch sets without it). hg unbundle patchset Sorry, couldn't resist ;) Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: visualization of language benchmarks
Robert Fraser wrote: Jérôme M. Berger wrote: Nick Sabalausky wrote: "Denis Koroskin" <2kor...@gmail.com> wrote in message news:op.uuthxivwo7c...@soldat.creatstudio.intranet... On Mon, 01 Jun 2009 03:21:42 +0400, Tim Matthews wrote: Knud Soerensen wrote: Tim Matthews wrote: It's things like this that make me want to get into visualization. Great article! Where's the D It is on 3,3 called Dlang. OK it is was on the 05 chart but I was expecting it to be on the updated 09 chart though. They seem to believe D is less of a player now. IIRC, there was no stable 64bit D compiler for Linux at the moment they moved to new hardware and thus D support was dropped. So they're benchmarks are only accurate for 64-bit? The shootout have 32-bit and 64-bit versions of the benchmarks, but they wanted to have the same benchmarks on both architectures. I don't know which version was used to generate the charts though. Jerome Well now that LDC supports 64-bit, could we convince them to put it back in? From the FAQ: "Why don't you include language X?" 8<--- Is the language implementation * Used? There are way too many dead languages and unused new languages - see The Language List and Computer Languages History * Interesting? Is there something significant and interesting about the language, and will that be revealed by these simple benchmark programs? (But look closely and you'll notice that we sometimes include languages just because we find them interesting.) If that wasn't discouraging enough: in too many cases we've been asked to include a language implementation, and been told that of course programs would be contributed, but once the language didn't seem to perform as-well-as hoped no more programs were contributed. We're interested in the whole range of performance - not just in the 5 programs which show a language implementation at it's best. We have no ambition to measure every Python implementation or every Haskell implementation or every C implementation - that's a chore for all you Python enthusiasts and Haskell enthusiasts and C enthusiasts, a chore which might be straightforward if you use our measurement scripts. We are unable to publish measurements for many commercial language implementations simply because their license conditions forbid it. We will accept and reject languages in a capricious and unfair fashion - so ask if we're interested before you start coding. >8=== http://shootout.alioth.debian.org/u64/faq.php#acceptable So we can always ask, but we have to be careful how we phrase it: somebody asked about LLVM and LDC on the forums and the discussion centred around LLVM as a C compiler: https://alioth.debian.org/forum/forum.php?thread_id=14508&forum_id=999&group_id=30402 Moreover, we have to be prepared to argue that D is used (should be easy: just point at the number of projects on dsource) and "interesting". The second is a lot more difficult because the definition of "interesting" is subjective: 8<--- Yes, there are just too many languages. Interesting means more like unusual - http://shootout.alioth.debian.org/u32/ats.php http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=lisaac&lang2=gpp&box=1 >8=== https://alioth.debian.org/forum/message.php?msg_id=181473&group_id=30402 Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Source control for all dmd source
Daniel Keep wrote: hasen wrote: ... Wow, tortoisegit? Seems so bloated, look at those screen shots, it's so confusing! Wow, git cli? Seems so bloated, look at all those commands, it's so confusing! It *is* confusing, it doesn't claim to be intuitive, it's aimed for developers, they're supposed to read tutorials/man pages to know how it works. Providing a gui that maps a "pull" button to a pull command is confusing because GUI's are supposed to be "discoverable" and "intuitive". No wonder I never knew how to properly use svn, I was so dependant on those GUIs, that I never knew what was going on under the surface. At least for me, the only sensible way to use svn is through the command line. GUIs for svn and git are confusing because well, you're not exactly sure what they're doing. As for your assertion that tortoisegit is confusing, let's look at those screenshots. The first is a context-dependant list of git commands. If you think that's confusing, then I can't imagine you're able to use the git cli at all, so let's assume you don't mean that one. Yes, I think it's confusing. Read above. I do use the git cli, it's easier because it makes more sense. Next we have a shot of it detecting a patch set and giving you context commands for those. I fail to see how that could be confusing. I haven't used patches with git, so I don't know what's in that corner of git. The commit dialog? Well, that's basically git commit -a, except you can actually modify what files are being committed in the dialog itself and it has a built-in editor. Yea? What are these options? [Sign] [OK] what's the difference between them? Actually, if you look at them, the dialogs are all just GUI versions of the various git tools themselves. So if you really find those confusing, I can only assume you find Git itself confusing. Look at this and tell me it's not confusing: http://www.jensroesner.de/wgetgui/wgetgui.png IMO it's wrong to just put the same command-line commands on the right-click menu, and call that a gui. Yes, because heaven forbid anyone makes our lives as developers easier. After all, no developer should EVER use a simplified interface when what they SHOULD be doing is memorising every command and all of its switches. The heresy! Well, if it makes your life easier, good for you. The humble git-gui is much better. Integrating those commands into the shell itself so that only the commands that make sense in context are shown, and actually tell the user what they're going to do is much better. Incidentally, I use both. TortoiseGit is great for anything of relative complexity as it actually helps you do it correctly (it took me a while to work out how to properly apply patch sets without it). What's more, it also helps you learn how to use git without constantly screwing up. I think if you don't know what you're doing you'll screw up anyway. I used to use SmartSVN, TortoiseSVN, and probably some other GUIs, and every so often I would screw something up and have no idea how to fix it. Why? because the GUI made me feel comfortable using svn without really knowing what the hell was going on. Many items under menus were confusing as hell. Many options for various tasks were also confusing as hell.
Re: Source control for all dmd source
hasen wrote: > ... > > Wow, tortoisegit? Seems so bloated, look at those screen shots, it's so > confusing! Wow, git cli? Seems so bloated, look at all those commands, it's so confusing! add am annotate apply archive bisect blame branch bundle cat-file check-attr checkout checkout-index check-ref-format cherry cherry-pick citool clean clone commit commit-tree config count-objects describe diff diff-files diff-index diff-tree fast-export fast-import fetch fetch-pack fetch--tool fmt-merge-msg got-for-each-ref format-patch fsck fsck-objects gc get-tar-commit-id grep hash-object http-fetch http-push index-pack init init-db log lost-found ls-files ls-remote ls-tree mailinfo mailsplit merge merge-base merge-index merge-octopus (wtf?) merge-one-file merge-our merge-recursive merge-resolve merge-subtree mergetool merge-tree mktag mktree mv name-rev pack-objects pack-redundant pack-refs parse-remote patch-id peek-remote prune prune-packed pull push quiltimport read-tree rebase rebase-interactive receive-pack reflog relink remote repack repo-config request-pull rerere reset revert rev-list rev-parse rm send-pack shortlog show show-branch show-index show-ref sh-setup stage stash status stripspace submodule svn symbolic-ref tag tar-tree unpack-file unpack-objects update-index update-ref update-server-info upload-archive upload-pack var verify-pack verify-tag web-browse whatchanged write-tree As for your assertion that tortoisegit is confusing, let's look at those screenshots. The first is a context-dependant list of git commands. If you think that's confusing, then I can't imagine you're able to use the git cli at all, so let's assume you don't mean that one. Next we have a shot of it detecting a patch set and giving you context commands for those. I fail to see how that could be confusing. The commit dialog? Well, that's basically git commit -a, except you can actually modify what files are being committed in the dialog itself and it has a built-in editor. Actually, if you look at them, the dialogs are all just GUI versions of the various git tools themselves. So if you really find those confusing, I can only assume you find Git itself confusing. > IMO it's wrong to just put the same command-line commands on the > right-click menu, and call that a gui. Yes, because heaven forbid anyone makes our lives as developers easier. After all, no developer should EVER use a simplified interface when what they SHOULD be doing is memorising every command and all of its switches. The heresy! > The humble git-gui is much better. Integrating those commands into the shell itself so that only the commands that make sense in context are shown, and actually tell the user what they're going to do is much better. Incidentally, I use both. TortoiseGit is great for anything of relative complexity as it actually helps you do it correctly (it took me a while to work out how to properly apply patch sets without it). What's more, it also helps you learn how to use git without constantly screwing up.
Re: Compiling in 64 system 32 bit program
Yeah Thanks! It Work!. "yum install glibc-devel.i586" Dan900 wrote: > [dan...@localhost bin]$ ./gdc -m32 dupa.d > /usr/bin/ld: crt1.o: No such file: No such file or directory > collect2: ld returned 1 exit status You will also need the 32-bit runtime libraries*... By default you would only have the 64-bit variants. * the package would be "glibc-devel", I believe So something like: yum install glibc-devel.i386 --anders
Re: Compiling in 64 system 32 bit program
Dan900 wrote: [dan...@localhost bin]$ ./gdc -m32 dupa.d /usr/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status You will also need the 32-bit runtime libraries*... By default you would only have the 64-bit variants. * the package would be "glibc-devel", I believe So something like: yum install glibc-devel.i386 --anders
Re: Compiling in 64 system 32 bit program
Dan900 wrote: I have GDC 64 on Linux Fedora 11, i wanna compile program to 32 bit systems but i have 64 bit system. Is this possible? when i type "--target-help" i have this error "gdc: error trying to exec 'cc1': execvp: Not Found" To compile 32-bit programs, you use the -m32 flag. --anders
Re: Compiling in 64 system 32 bit program
[dan...@localhost bin]$ ./gdc -m32 dupa.d /usr/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status ??
Compiling in 64 system 32 bit program
I have GDC 64 on Linux Fedora 11, i wanna compile program to 32 bit systems but i have 64 bit system. Is this possible? when i type "--target-help" i have this error "gdc: error trying to exec 'cc1': execvp: Not Found"
Re: visualization of language benchmarks
Jérôme M. Berger wrote: Nick Sabalausky wrote: "Denis Koroskin" <2kor...@gmail.com> wrote in message news:op.uuthxivwo7c...@soldat.creatstudio.intranet... On Mon, 01 Jun 2009 03:21:42 +0400, Tim Matthews wrote: Knud Soerensen wrote: Tim Matthews wrote: It's things like this that make me want to get into visualization. Great article! Where's the D It is on 3,3 called Dlang. OK it is was on the 05 chart but I was expecting it to be on the updated 09 chart though. They seem to believe D is less of a player now. IIRC, there was no stable 64bit D compiler for Linux at the moment they moved to new hardware and thus D support was dropped. So they're benchmarks are only accurate for 64-bit? The shootout have 32-bit and 64-bit versions of the benchmarks, but they wanted to have the same benchmarks on both architectures. I don't know which version was used to generate the charts though. Jerome Well now that LDC supports 64-bit, could we convince them to put it back in?
Re: Source control for all dmd source
Christopher Wright wrote: Leandro Lucarella wrote: "Jérôme M. Berger", el 31 de mayo a las 19:03 me escribiste: Leandro Lucarella wrote: Well, that's great to hear! As Robert said, please tell if you need any help. Please, please, please consider using a distributed SCM (I think git would be ideal but mercurial is good too). That would make merging and branching a lot easier. Git is a bad choice because of its poor Windows support. Mercurial or Bazaar are much better in this regard. That's a mith, Git is pretty much supported in Windows now. I know people that uses it in a regular basis. See: http://code.google.com/p/msysgit/ I've used tortoise-git: http://code.google.com/p/tortoisegit/ It worked pretty well, though I didn't spend much time with it. Wow, tortoisegit? Seems so bloated, look at those screen shots, it's so confusing! IMO it's wrong to just put the same command-line commands on the right-click menu, and call that a gui. The humble git-gui is much better.
Re: visualization of language benchmarks
Nick Sabalausky wrote: "Denis Koroskin" <2kor...@gmail.com> wrote in message news:op.uuthxivwo7c...@soldat.creatstudio.intranet... On Mon, 01 Jun 2009 03:21:42 +0400, Tim Matthews wrote: Knud Soerensen wrote: Tim Matthews wrote: It's things like this that make me want to get into visualization. Great article! Where's the D It is on 3,3 called Dlang. OK it is was on the 05 chart but I was expecting it to be on the updated 09 chart though. They seem to believe D is less of a player now. IIRC, there was no stable 64bit D compiler for Linux at the moment they moved to new hardware and thus D support was dropped. So they're benchmarks are only accurate for 64-bit? The shootout have 32-bit and 64-bit versions of the benchmarks, but they wanted to have the same benchmarks on both architectures. I don't know which version was used to generate the charts though. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Why are void[] contents marked as having pointers?
On Sun, 31 May 2009 23:24:09 +0300, Andrei Alexandrescu wrote: > Another alternative would be to allow implicitly casting arrays of any > type to const(ubyte)[] which is always safe. But I think this is too > much ado about nothing - you're avoiding the type system to start with, > so use ubyte, insert a cast, and call it a day. If you have too many > casts, the problem is most likely elsewhere so that argument I'm not > buying. I've thought about this for a bit. If we allow any *non-reference* type except void[] to implicitly cast to ubyte[], but still allow implicitly casting ubyte[] to void[], it will put ubyte[] in the perfect spot in the type hierarchy - it'll allow safely (portability issues notwithstanding) getting the representation of value-type (POD) arrays, while still allowing abstracting it even further to the "might have pointers" type - at which point it is unsafe to access individual bytes, which void[] disallows without casts. -- Best regards, Vladimir mailto:thecybersha...@gmail.com
