[sage-devel] Re: Another build error
On 2017-12-07, Simon King wrote: > Hi! > > Building Sage again, I get the error > InternalError: Internal compiler error: 'cysignals/signals.pxi' not > found > > Unfortunately, the error did not go away after "make distclean". > > What can I do? The error occurs on some local branch (different from > develop), however I didn't touch cysignals. Strangely, git status mentions src/sage/libs/cypari2/ which my local branch is *not* touching. So, what's happening? Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Another build error
Hi François, On 2017-12-07, François Bissey wrote: >> Strangely, git status mentions >>src/sage/libs/cypari2/ >> which my local branch is *not* touching. So, what's happening? >> > > Anything in that folder? That folder has been removed when cypari2 has been > made a separate package. git sometimes don’t remove folders that have been > removed. What is the exact git status for that folder? Sorry, I cannot tell exactly, as I deleted the folder and then tried "make" (without "make distclean") again. It did not succeed. Anyway. The branch used to be an old one. I checked it out and then rebased on top of the latest develop. Do I understand correctly that while rebasing, git failed to remove the cypari2 folder? Cheers, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Another build error
On 2017-12-07, François Bissey wrote: > Seems like it. Which is why I asked if there was anything in it. I think it was empty before I removed it. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Another build error
> > Anyway. The branch used to be an old one. I checked it out and then > rebased on top of the latest develop. Do I understand correctly that > while rebasing, git failed to remove the cypari2 folder? > > IMO, a better practice is to merge in old branches to a branch based off develop. If you want to rebase, then run rebase. That way you never have old cruft and have to watch Sage do a massive rebuild of things with only changed timestamps. For example $ git checkout -b branch_name develop $ git merge branch_name $ git rebase develop Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Another build error
On Friday, December 8, 2017 at 8:30:48 AM UTC+9, Travis Scrimshaw wrote: > > > >> Anyway. The branch used to be an old one. I checked it out and then >> rebased on top of the latest develop. Do I understand correctly that >> while rebasing, git failed to remove the cypari2 folder? >> >> IMO, a better practice is to merge in old branches to a branch based off > develop. > I also adopted this practice after many trial and errors. Shouldn't we make it an official recommendation and include it in the developer manual? On the other hand, one problem with the practice is that the new branch based off develop does not have the tracking information of the old branch. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Another build error
Hi Travis, On 2017-12-07, Travis Scrimshaw wrote: > IMO, a better practice is to merge in old branches to a branch based off > develop. If you want to rebase, then run rebase. That way you never have > old cruft and have to watch Sage do a massive rebuild of things with only > changed timestamps. For example > > $ git checkout -b branch_name develop > $ git merge branch_name > $ git rebase develop I am not sure if I understand that procedure correctly. Where does the old branch comes into play? Should the second line perhaps be $ git merge old_branch ? Why would you rebase if old_branch merges cleanly into develop? And even if you abstain from rebasing: Assume you have local_old_branch that is identical with remote_old_branch in the branch field of Trac ticket 12345. The purpose is to somehow merge it with the latest develop, and according to your suggestion one does $ git checkout -b new_branch_name develop $ git merge local_old_branch and then push new_branch_name to #12345. Would that mean to force-push? Or would a normal push suffice? Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Another build error
On Saturday, December 9, 2017 at 5:10:51 AM UTC+9, Simon King wrote: > > Hi Travis, > > On 2017-12-07, Travis Scrimshaw > wrote: > > IMO, a better practice is to merge in old branches to a branch based off > > develop. If you want to rebase, then run rebase. That way you never have > > old cruft and have to watch Sage do a massive rebuild of things with > only > > changed timestamps. For example > > > > $ git checkout -b branch_name develop > > $ git merge branch_name > > $ git rebase develop > > I am not sure if I understand that procedure correctly. Where does the > old branch comes into play? Should the second line perhaps be > $ git merge old_branch > ? > > Why would you rebase if old_branch merges cleanly into develop? > > And even if you abstain from rebasing: Assume you have local_old_branch > that is identical with remote_old_branch in the branch field of Trac > ticket > 12345. The purpose is to somehow merge it with the latest develop, and > according to your suggestion one does > $ git checkout -b new_branch_name develop > $ git merge local_old_branch > and then push new_branch_name to #12345. Would that mean to force-push? Or > would a normal push suffice? > I guess Travis' idea is the same with my own practice. Suppose the feature branch is "trac12345_dev". The procedure to "rebase" the feature branch to the latest "develop" without massive rebuild is: $ git branch -m trac12345_dev trac12345 $ git checkout -b trac12345_dev develop $ git merge trac12345 $ git branch -d trac12345 and then push "trac12345_dev" to trac. This is a normal push. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Another build error
> > IMO, a better practice is to merge in old branches to a branch based off > > develop. If you want to rebase, then run rebase. That way you never have > > old cruft and have to watch Sage do a massive rebuild of things with > only > > changed timestamps. For example > > > > $ git checkout -b branch_name develop > > $ git merge branch_name > > $ git rebase develop > > I am not sure if I understand that procedure correctly. Where does the > old branch comes into play? Should the second line perhaps be > $ git merge old_branch > ? > > Why would you rebase if old_branch merges cleanly into develop? > > And even if you abstain from rebasing: Assume you have local_old_branch > that is identical with remote_old_branch in the branch field of Trac > ticket > 12345. The purpose is to somehow merge it with the latest develop, and > according to your suggestion one does > $ git checkout -b new_branch_name develop > $ git merge local_old_branch > and then push new_branch_name to #12345. Would that mean to force-push? Or > would a normal push suffice? > > Personally, I never rebase on published branches because that overwrites history (although I will do this on my personal branches before I push them). However, if you do $ git fetch trac old_branch:local_branch_name $ git checkout local_branch_name $ git merge develop you reset everything to the version that old_branch was at, so all of the timestamps get updates, and then the merge resets them again to the state of develop. So as far as make knows, you have just changed everything. Now if you follow the procedure with no rebasing, then you can do a normal push and the branch just picks up a merge commit. I also never have branches that are not based on develop. I make it a point to update all of my local branches in order to avoid accidentally switching versions. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Another build error
> On 8/12/2017, at 11:12, Simon King wrote: > > On 2017-12-07, Simon King wrote: >> Hi! >> >> Building Sage again, I get the error >> InternalError: Internal compiler error: 'cysignals/signals.pxi' not >> found >> >> Unfortunately, the error did not go away after "make distclean". >> >> What can I do? The error occurs on some local branch (different from >> develop), however I didn't touch cysignals. > > Strangely, git status mentions >src/sage/libs/cypari2/ > which my local branch is *not* touching. So, what's happening? > Anything in that folder? That folder has been removed when cypari2 has been made a separate package. git sometimes don’t remove folders that have been removed. What is the exact git status for that folder? François -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Another build error
> On 8/12/2017, at 11:48, Simon King wrote: > > Hi François, > > On 2017-12-07, François Bissey wrote: >>> Strangely, git status mentions >>> src/sage/libs/cypari2/ >>> which my local branch is *not* touching. So, what's happening? >>> >> >> Anything in that folder? That folder has been removed when cypari2 has been >> made a separate package. git sometimes don’t remove folders that have been >> removed. What is the exact git status for that folder? > > Sorry, I cannot tell exactly, as I deleted the folder and then tried > "make" (without "make distclean") again. It did not succeed. > > Anyway. The branch used to be an old one. I checked it out and then > rebased on top of the latest develop. Do I understand correctly that > while rebasing, git failed to remove the cypari2 folder? > Seems like it. Which is why I asked if there was anything in it. François -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Another build error
I have the same problem : charpent@p-202-021:/usr/local/sage-8$ git status Sur la branche 8_1_R_343 Fichiers non suivis: (utilisez "git add ..." pour inclure dans ce qui sera validé) src/sage/libs/cypari2/ aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre) charpent@p-202-021:/usr/local/sage-8$ git status src/sage/libs/cypari2/ Sur la branche 8_1_R_343 Fichiers non suivis: (utilisez "git add ..." pour inclure dans ce qui sera validé) src/sage/libs/cypari2/auto_gen.pxi src/sage/libs/cypari2/auto_instance.pxi aucune modification ajoutée à la validation mais des fichiers non suivis sont présents (utilisez "git add" pour les suivre) charpent@p-202-021:/usr/local/sage-8$ ls -lR src/sage/libs/cypari2 src/sage/libs/cypari2: total 908 -rw-r--r-- 1 charpent charpent 860368 avril 25 2017 auto_gen.pxi -rw-r--r-- 1 charpent charpent 57753 avril 25 2017 auto_instance.pxi drwxr-xr-x 2 charpent charpent 4096 avril 1 2017 __pycache__ src/sage/libs/cypari2/__pycache__: total 4 -rw-r--r-- 1 charpent charpent 247 avril 1 2017 __init__.cpython-35.pyc This is my workhorse branch, updated often. Since I have had a lot of upfddates since april, it seems to be dead wood. I tend to think that I can "rm -Rf /usr/sage/libs/cypary2" without ill effects. What do you think ? -- Emmanuel Charpentier Le jeudi 7 décembre 2017 23:19:51 UTC+1, François Bissey a écrit : > > > > > On 8/12/2017, at 11:12, Simon King > > wrote: > > > > On 2017-12-07, Simon King > wrote: > >> Hi! > >> > >> Building Sage again, I get the error > >> InternalError: Internal compiler error: 'cysignals/signals.pxi' not > >> found > >> > >> Unfortunately, the error did not go away after "make distclean". > >> > >> What can I do? The error occurs on some local branch (different from > >> develop), however I didn't touch cysignals. > > > > Strangely, git status mentions > >src/sage/libs/cypari2/ > > which my local branch is *not* touching. So, what's happening? > > > > Anything in that folder? That folder has been removed when cypari2 has > been > made a separate package. git sometimes don’t remove folders that have been > removed. What is the exact git status for that folder? > > François > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
