Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote: eles: Speaking about that, why DMD's source files are written in C++ but bear extension .c? You seem to appreciate for yourselves a freedom that he denies to others. Thank you for bringing that good example. Forbidding arbitrary extensions for D code, and enforcing a common standard name helps avoid mistakes like those ".c" extensions in the C++ sources, that numerous persons keep criticizing. The advantages of a standard suffix for D code are way larger than the disadvantages. A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth Well, then God created humans...
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:39:27 UTC, eles wrote: On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring wrote: Am 31.10.2013 16:22, schrieb eles: On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring no problem :) so tell the story what would happen if D scripts will be without .d? is your Boss then more interested or can you introduce D-scripts then silently - what would happen? He won't really care as long as I don't ask him to modify his scripts to update the names of those used by me. The latter are already hard-coded in his and others. Yes, this has a solution: use of hardlinks (of identical-content, different name files). I already explained and acknowledged that in the very first post. But is cumbersome and unpleasant and bad for backup-ing. Why not simply rename .d to . then compile, rename back using a script? It might add a few extra seconds for very large projects but otherwise insignificant and should work most of the time. Basically you'll use the script or wrapper app instead of whatever compile you are using.
Re: Start of dmd 2.064 beta program
On Tuesday, 10 December 2013 at 09:44:38 UTC, Frustrated wrote: On Thursday, 31 October 2013 at 15:39:27 UTC, eles wrote: On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring wrote: Am 31.10.2013 16:22, schrieb eles: On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring Why not simply rename .d to . then compile, rename back using a script? It might add a few extra seconds for very large projects but otherwise insignificant and should work most of the time. Basically you'll use the script or wrapper app instead of whatever compile you are using. You are overreacting to a maybe bad joke, but I must say that I really love the solution you propose. Is even better than the one with hardlinks. The only thing that I don't have yet is a third hand to keep the window open while my fifth foot is doing some tricks with the a crow's nest. This would be quite a workable workaround, don't you think?
Re: Start of dmd 2.064 beta program
On Tuesday, 10 December 2013 at 10:10:09 UTC, eles wrote: On Tuesday, 10 December 2013 at 09:44:38 UTC, Frustrated wrote: On Thursday, 31 October 2013 at 15:39:27 UTC, eles wrote: On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring wrote: Am 31.10.2013 16:22, schrieb eles: On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring The only thing that I don't have yet is a third hand to keep the window open while my fifth foot is doing some tricks with the a crow's nest. I mean, all that to entertain the compiler and keep it happy :)
Re: Fedora RPMs
On Mon, 2013-12-09 at 15:54 +0100, Dejan Lekic wrote: […] > > Btw, I forgot to tell you... I talked to fedora people about > having dmd in Fedora. They said it will probably be rejected > because of the backend license, because they are not allowed to > freely distribute the software. So I guess we will most likely > have to setup our own YUM repository on dlang.org - that is > probably the best course of action. If someone has better idea, > please share it. RPM Fusion seems to be the place for RPMs that cannot be part of the Fedora distribution. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Build Master: Progress toward 2.065
On 12/10/13, 2:16 AM, Jacob Carlborg wrote: On 2013-12-09 16:30, Jacob Carlborg wrote: Make sure I got GCC, I don't think the test suite passes if DMD built with Clang. * you got. Ok... will do.
Re: Build Master: Progress toward 2.065
On 12/10/13, 12:45 AM, Kenji Hara wrote: On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote: On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote: 2) What is the process to update a branch with all changes master? I will need to do this because a lot of changes have occurred since the 2.065 branches were created but the actual betas are not yet prepared. Going forward, this is the only time this will occur. If branch does not have own commits to be preserved and needs to just be synced with master state (assuming D-Programming-Language remote is named `upstream`): git fetch upstream # download current remote state git checkout 2.065 # go to release branch git reset --hard upstream/master # make it identical to current master git push -f origin 2.065 # update own fork git push -f upstream 2.065 # update branch in core repos, careful here! I can't imagine any other case when one may want to update release branch from master so it must the what you need. Note that, at least phobos repository already has some own commits in 2.065 branch. Kenji Hara I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch. Andrew
Re: Build Master: Progress toward 2.065
On Tuesday, 10 December 2013 at 05:45:26 UTC, Kenji Hara wrote: On Monday, 9 December 2013 at 15:51:47 UTC, Dicebot wrote: On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote: 2) What is the process to update a branch with all changes master? I will need to do this because a lot of changes have occurred since the 2.065 branches were created but the actual betas are not yet prepared. Going forward, this is the only time this will occur. If branch does not have own commits to be preserved and needs to just be synced with master state (assuming D-Programming-Language remote is named `upstream`): git fetch upstream # download current remote state git checkout 2.065 # go to release branch git reset --hard upstream/master # make it identical to current master git push -f origin 2.065 # update own fork git push -f upstream 2.065 # update branch in core repos, careful here! I can't imagine any other case when one may want to update release branch from master so it must the what you need. Note that, at least phobos repository already has some own commits in 2.065 branch. Kenji Hara So, technically, there has been already some release work ongoing in that branch but now you want to restart it with new base? git fetch upstream git checkout 2.065 git rebase upstream/master # assumes it has common point with master earlier in history # resolve conflicts if any git push -f origin 2.065 # any rewrite of history is likely to require force push git push -f upstream 2.065
Re: Build Master: Progress toward 2.065
On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote: I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch. cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit.
Re: Build Master: Progress toward 2.065
On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote: On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote: I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch. cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit. I'd argue that the release branches should be considered public history and thus never rebased. You can always just merge master into them... David
Re: Build Master: Progress toward 2.065
On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote: On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote: cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit. Or just dropping and start again. For a first try is OK to do several trials until the things get on track.
Re: Build Master: Progress toward 2.065
On Tuesday, 10 December 2013 at 13:25:02 UTC, David Nadlinger wrote: On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote: On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote: I which case, updating with master will be counter productive. Thanks for the heads up. I will just have to rely on the devs to cherry-pick what was not originally included in the branch. cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit. I'd argue that the release branches should be considered public history and thus never rebased. You can always just merge master into them... David Can't agree. Release _tags_ are public. Release branches exist primarily to organize development. Merging master into release branch working on it and then merging all back to master creates very messy making it much harder to say what commits where introduces by release process.
Re: Build Master: Progress toward 2.065
On Tuesday, 10 December 2013 at 13:30:22 UTC, Dicebot wrote: Can't agree. Release _tags_ are public. Release branches exist primarily to organize development. I'm not talking about public in the sense of them being an artefact we want to provide to end-users, but just in the sense that more than one person might need to work on the release branch. As I'm sure you are aware, you'd have to tell everybody to reset their local branches every time the upstream one is updated. Or do you expect only one person to ever commit to the release branch? Of course, ideally commits would go on the release branch first and from there be merged into master (or to other, newer version branches). But if the question is how to fix the current situation where this isn't the case, I'm not sure that rewriting public history is the best option. David
Re: Build Master: Progress toward 2.065
On Tuesday, 10 December 2013 at 13:37:11 UTC, David Nadlinger wrote: On Tuesday, 10 December 2013 at 13:30:22 UTC, Dicebot wrote: Can't agree. Release _tags_ are public. Release branches exist primarily to organize development. I'm not talking about public in the sense of them being an artefact we want to provide to end-users, but just in the sense that more than one person might need to work on the release branch. As I'm sure you are aware, you'd have to tell everybody to reset their local branches every time the upstream one is updated. Or do you expect only one person to ever commit to the release branch? Of course, ideally commits would go on the release branch first and from there be merged into master (or to other, newer version branches). But if the question is how to fix the current situation where this isn't the case, I'm not sure that rewriting public history is the best option. David It is not a problem to reset local branches on rare occasions like this one, whatever developer count is. Reason why rebasing of public branches is discouraged is not some abstract inconvenience of collaboration - it is the fact that commit hashes change in history and anything that has been pointing to part of history that got rewritten will be broken (especially important if, for example, commit hashes are embedded into deployed builds). This is not the case here. There has not been a single tag on this branch and not a single packaged binary built from it. Just is just a development snapshot, rebasing it is no different than creating a new one. As it won't happen under normal conditions anyway, I fail to see the issue.
Re: Build Master: Progress toward 2.065
Dicebot, el 10 de December a las 14:01 me escribiste: > On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote: > >I which case, updating with master will be counter productive. > >Thanks for the heads up. I will just have to rely on the devs to > >cherry-pick what was not originally included in the branch. > > cherry-picking is discouraged in that scenario as it will complicate > merging 2.065 branch back into master after release. rebase sounds > like best fit. I don't understand. Rebasing the release branch on top of master shouldn't be an option, as it means you are taking all the changes to master and put them in the release branch. That's just using master as a release branch. The other way around would be crazy. What problems do you see merging cherry-picked stuff back into master? IIRC git should be smart enough to recognize duplicated commits and ignore them, at least if you merge often. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Hola soy Angie. Quería preguntarles como inserto un archivo .cab (paquete hecho en Visual Basic contiene una librería y un ocx) en Internet Explorer para después me deje trabajar en PHP con este .cab
Re: Build Master: Progress toward 2.065
On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella wrote: I don't understand. Rebasing the release branch on top of master shouldn't be an option, as it means you are taking all the changes to master and put them in the release branch. That's just using master as a release branch. The other way around would be crazy. Yes, of course, it is not a normal thing to do. As far as I understand, Andrew wants to restart release branch from scratch, based on current master state (because old base happened before he started working on release management). In that case it is a natural (and exceptional) solution. What problems do you see merging cherry-picked stuff back into master? IIRC git should be smart enough to recognize duplicated commits and ignore them, at least if you merge often. In my experience it was not smart enough. It may have changed in latest versions of course.
Re: Build Master: Progress toward 2.065
On 12/10/13, 10:18 AM, Dicebot wrote: On Tuesday, 10 December 2013 at 15:09:13 UTC, Leandro Lucarella wrote: I don't understand. Rebasing the release branch on top of master shouldn't be an option, as it means you are taking all the changes to master and put them in the release branch. That's just using master as a release branch. The other way around would be crazy. Yes, of course, it is not a normal thing to do. As far as I understand, Andrew wants to restart release branch from scratch, based on current master state (because old base happened before he started working on release management). In that case it is a natural (and exceptional) solution. Yes. This is precisely the case and exactly what I'm trying to achieve. My hope is that by doing this I will not be adversely effecting any code already merged into the branch. If there is a chance that this might happen, I would rather cherry-pick the items that must be included or simply forgo such inclusion until the next release. What problems do you see merging cherry-picked stuff back into master? IIRC git should be smart enough to recognize duplicated commits and ignore them, at least if you merge often. In my experience it was not smart enough. It may have changed in latest versions of course.
