* merging etc @ 2007-08-19 3:17 Miles Bader [not found] ` <200708211523.l7LFNnVl000876@oogie-boogie.ics.uci.edu> 0 siblings, 1 reply; 67+ messages in thread From: Miles Bader @ 2007-08-19 3:17 UTC (permalink / raw) To: Emacs-Devel Just a note -- my usual emacs merging activity is going to be kind of slow for a while, as my home internet connection (and phone!) has been cut off. [I'm sending this from a public machine at mangaland.] Thanks, -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 67+ messages in thread
[parent not found: <200708211523.l7LFNnVl000876@oogie-boogie.ics.uci.edu>]
[parent not found: <buo3aycknp8.fsf@dhapc248.dev.necel.com>]
[parent not found: <200708220820.l7M8KbIt026014@oogie-boogie.ics.uci.edu>]
[parent not found: <fc339e4a0708220237v3b90ec6fwde90eba1ca936e91@mail.gmail.com>]
* Re: merging etc [not found] ` <fc339e4a0708220237v3b90ec6fwde90eba1ca936e91@mail.gmail.com> @ 2007-08-22 11:55 ` Miles Bader 2007-08-22 15:33 ` Stefan Monnier ` (3 more replies) 0 siblings, 4 replies; 67+ messages in thread From: Miles Bader @ 2007-08-22 11:55 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Juri Linkov, Karoly Lorentey, Emacs-Devel Ok, I've put all the changelog info from the arch logs into "ChangeLog.multi-tty" files in the various emacs directories (on the multi-tty branch). I split the entries by directory and generally cleaned up the text. Richard also said he wants the multi-tty changelogs "crunched" before merging -- i.e., essentially replacing many historical entries for a given function/variable by a single entry for it with all the changes (or in the case of a new function/variable, all entries for it except "New function/variable" can be dropped entirely). I'm not sure how this is supposed to work for multiple authors changing the same function.... (one changelog entry per author?). That seems like a daunting task given the size of the logs though... -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-22 11:55 ` Miles Bader @ 2007-08-22 15:33 ` Stefan Monnier 2007-08-23 0:19 ` Juri Linkov 2007-08-23 20:58 ` Richard Stallman 2007-08-23 0:45 ` Richard Stallman ` (2 subsequent siblings) 3 siblings, 2 replies; 67+ messages in thread From: Stefan Monnier @ 2007-08-22 15:33 UTC (permalink / raw) To: Miles Bader; +Cc: Juri Linkov, Dan Nicolaescu, Karoly Lorentey, Emacs-Devel > Ok, I've put all the changelog info from the arch logs into > "ChangeLog.multi-tty" files in the various emacs directories (on the > multi-tty branch). I split the entries by directory and generally > cleaned up the text. Thank you very much. > Richard also said he wants the multi-tty changelogs "crunched" before > merging -- i.e., essentially replacing many historical entries for a > given function/variable by a single entry for it with all the changes > (or in the case of a new function/variable, all entries for it except > "New function/variable" can be dropped entirely). I'm not sure how > this is supposed to work for multiple authors changing the same > function.... (one changelog entry per author?). > That seems like a daunting task given the size of the logs though... I actually would rather keep the whole uncrunched text. I know it can be found on the branch, but if we insist on putting more than just "merge from branch", then we may as well keep it all. Stefan ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-22 15:33 ` Stefan Monnier @ 2007-08-23 0:19 ` Juri Linkov 2007-08-23 20:58 ` Richard Stallman 2007-08-23 20:58 ` Richard Stallman 1 sibling, 1 reply; 67+ messages in thread From: Juri Linkov @ 2007-08-23 0:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: dann, emacs-devel, karoly, miles >> Richard also said he wants the multi-tty changelogs "crunched" before >> merging -- i.e., essentially replacing many historical entries for a >> given function/variable by a single entry for it with all the changes >> (or in the case of a new function/variable, all entries for it except >> "New function/variable" can be dropped entirely). I'm not sure how >> this is supposed to work for multiple authors changing the same >> function.... (one changelog entry per author?). > >> That seems like a daunting task given the size of the logs though... > > I actually would rather keep the whole uncrunched text. I know it can be > found on the branch, but if we insist on putting more than just "merge from > branch", then we may as well keep it all. And maybe after adding ChangeLog entries from multy-tty to the trunk's ChangeLog to change all dates (without crunching changelog entries) to the date of sync with the trunk. This will look as all multy-tty changes were made on the same day and won't break the chronology in ChangeLog. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-23 0:19 ` Juri Linkov @ 2007-08-23 20:58 ` Richard Stallman 2007-08-24 8:01 ` joakim 0 siblings, 1 reply; 67+ messages in thread From: Richard Stallman @ 2007-08-23 20:58 UTC (permalink / raw) To: Juri Linkov; +Cc: karoly, miles, dann, monnier, emacs-devel And maybe after adding ChangeLog entries from multy-tty to the trunk's ChangeLog to change all dates (without crunching changelog entries) to the date of sync with the trunk. This will look as all multy-tty changes were made on the same day and won't break the chronology in ChangeLog. Changing all the dates to the date of installation in the trunk is essential. That is what permit the second step of combining and simplifying the various entries. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-23 20:58 ` Richard Stallman @ 2007-08-24 8:01 ` joakim 2007-08-24 8:37 ` Miles Bader ` (2 more replies) 0 siblings, 3 replies; 67+ messages in thread From: joakim @ 2007-08-24 8:01 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > And maybe after adding ChangeLog entries from multy-tty to the trunk's > ChangeLog to change all dates (without crunching changelog entries) to the > date of sync with the trunk. This will look as all multy-tty changes were > made on the same day and won't break the chronology in ChangeLog. > > Changing all the dates to the date of installation in the trunk > is essential. That is what permit the second step of combining > and simplifying the various entries. If a clear and concise algorithm can be presented on how to proceed with this "crunching" I can atempt to do so. I am motivated to get the mtty functionality into emacs core, even if I wouldn't do the merging this way myself. (I hope the mtty history wont be lost this way, that would really not be very good) -- Joakim Verona ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-24 8:01 ` joakim @ 2007-08-24 8:37 ` Miles Bader 2007-08-24 8:46 ` Leo 2007-08-25 4:07 ` merging etc Richard Stallman 2 siblings, 0 replies; 67+ messages in thread From: Miles Bader @ 2007-08-24 8:37 UTC (permalink / raw) To: emacs-devel joakim@verona.se writes: > I wouldn't do the merging this way myself. (I hope the mtty history > wont be lost this way, that would really not be very good) The raw(ish) changelog entries are already in CVS on the multi-tty branch (in per-directory "ChangeLog.multi-tty" files), so in that sense, at least, the history won't be "lost".... -miles -- "Suppose we've chosen the wrong god. Every time we go to church we're just making him madder and madder." -- Homer Simpson ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-24 8:01 ` joakim 2007-08-24 8:37 ` Miles Bader @ 2007-08-24 8:46 ` Leo 2007-08-24 9:03 ` joakim 2007-08-24 10:08 ` David Kastrup 2007-08-25 4:07 ` merging etc Richard Stallman 2 siblings, 2 replies; 67+ messages in thread From: Leo @ 2007-08-24 8:46 UTC (permalink / raw) To: emacs-devel On 2007-08-24 09:01 +0100, joakim@verona.se wrote: > I am motivated to get the mtty functionality into emacs core, even if > I wouldn't do the merging this way myself. (I hope the mtty history > wont be lost this way, that would really not be very good) Many people would be grateful for your effort ;) Maybe this merging difficulty can be avoided in future. I see one option for Emacs -- GIT¹. Footnotes: ¹ http://git.or.cz/ -- Leo <sdl.web AT gmail.com> (GPG Key: 9283AA3F) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-24 8:46 ` Leo @ 2007-08-24 9:03 ` joakim 2007-08-25 4:07 ` Richard Stallman 2007-08-24 10:08 ` David Kastrup 1 sibling, 1 reply; 67+ messages in thread From: joakim @ 2007-08-24 9:03 UTC (permalink / raw) To: emacs-devel Leo <sdl.web@gmail.com> writes: > On 2007-08-24 09:01 +0100, joakim@verona.se wrote: >> I am motivated to get the mtty functionality into emacs core, even if >> I wouldn't do the merging this way myself. (I hope the mtty history >> wont be lost this way, that would really not be very good) > > Many people would be grateful for your effort ;) > > Maybe this merging difficulty can be avoided in future. I see one option > for Emacs -- GIT¹. The way I'm used to working, there wouldnt be much of a "changelog" at all, that information would be extracted from a SCM. But I think even CVS would be able to create changelogs directly from the commits the way Emacs maintainers wants it, so I dont see what switching to git would change in this regard. Its more of a cultural issue. (git would of course bring us many other benefits) > Footnotes: > ¹ http://git.or.cz/-- > Leo <sdl.web AT gmail.com> (GPG Key: 9283AA3F) -- Joakim Verona ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-24 9:03 ` joakim @ 2007-08-25 4:07 ` Richard Stallman 2007-08-25 12:45 ` joakim 2007-08-25 19:12 ` Glenn Morris 0 siblings, 2 replies; 67+ messages in thread From: Richard Stallman @ 2007-08-25 4:07 UTC (permalink / raw) To: joakim; +Cc: emacs-devel But I think even CVS would be able to create changelogs directly from the commits the way Emacs maintainers wants it, so I dont see what switching to git would change in this regard. Its more of a cultural issue. (git would of course bring us many other benefits) The CVS change logs are insufficient because they do not list the authors' names. They list who checked in the change. So that simply is not an option. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-25 4:07 ` Richard Stallman @ 2007-08-25 12:45 ` joakim 2007-08-26 2:08 ` Glenn Morris 2007-08-26 14:56 ` merging etc Richard Stallman 2007-08-25 19:12 ` Glenn Morris 1 sibling, 2 replies; 67+ messages in thread From: joakim @ 2007-08-25 12:45 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > But I think even CVS would be able to create changelogs directly from > the commits the way Emacs maintainers wants it, so I dont see what > switching to git would change in this regard. Its more of a cultural > issue. (git would of course bring us many other benefits) > > The CVS change logs are insufficient because they do not list the > authors' names. They list who checked in the change. > > So that simply is not an option. That could surely be fixed by adding meta data to the commit. But I'm not going to argue this point. Instead I would like ask if its possible to do the merge like this: - people knowledgeable how to perform the merge with the given tool contraints do so now, merging mtty to head. - In the changelog there will be a placeholder: ------- Merge performed from mtty branch: TODO insert crunched mtty changelog here. ------- - somewhere in the Emacs tree there will be a mtty changelog. - The mtty changelog is crunched piece by piece, and inserted into the main changelog incrementaly. The corresponding passage in the mtty changelog is removed to keep track of progress. I would like to do it this way so several people can work together on the crunching, and so the merging wont be delayed so people can start find actual functional problems. Furthermore I dont feel very comfortable with cvs, and this way feels less likely to mess up. -- Joakim Verona ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-25 12:45 ` joakim @ 2007-08-26 2:08 ` Glenn Morris 2007-08-26 2:16 ` gnus inserts headers in body [was Re: merging etc] Glenn Morris 2007-08-26 14:56 ` merging etc Richard Stallman 1 sibling, 1 reply; 67+ messages in thread From: Glenn Morris @ 2007-08-26 2:08 UTC (permalink / raw) To: joakim; +Cc: emacs-devel joakim@verona.se wrote: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > - somewhere in the Emacs tree there will be a mtty changelog. They already exist, in the multi-tty CVS branch with the name ChangeLog.multi-tty. > - The mtty changelog is crunched piece by piece, and inserted into the > main changelog incrementaly. The corresponding passage in the mtty > changelog is removed to keep track of progress. > > I would like to do it this way so several people can work together on > the crunching People can do this right now. Simply edit ChangeLog.multi-tty to make whatever improvements you can, then check in the changes as you go along (or send diffs). Date: Sat, 25 Aug 2007 22:08:05 -0400 In-Reply-To: <m3mywf3hqi.fsf@kurono.home> (joakim@verona.se's message of "Sat, 25 Aug 2007 14:45:41 +0200") Message-ID: <peejhr2gl6.fsf@fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) ^ permalink raw reply [flat|nested] 67+ messages in thread
* gnus inserts headers in body [was Re: merging etc] 2007-08-26 2:08 ` Glenn Morris @ 2007-08-26 2:16 ` Glenn Morris 2007-08-26 7:45 ` gnus inserts headers in body Reiner Steib 0 siblings, 1 reply; 67+ messages in thread From: Glenn Morris @ 2007-08-26 2:16 UTC (permalink / raw) To: emacs-devel Glenn Morris wrote: <garbled message with headers in body> Dammit, why does Gnus do that to me sometimes when I edit a draft then send it? Anyone else ever bothered by this? I've always suspected it may be some Gnus/VM interaction with different settings for some message header separator... ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: gnus inserts headers in body 2007-08-26 2:16 ` gnus inserts headers in body [was Re: merging etc] Glenn Morris @ 2007-08-26 7:45 ` Reiner Steib 2007-08-27 1:32 ` Glenn Morris 0 siblings, 1 reply; 67+ messages in thread From: Reiner Steib @ 2007-08-26 7:45 UTC (permalink / raw) To: Glenn Morris, Gnus; +Cc: emacs-devel [ Adding ding@gnus ] On Sun, Aug 26 2007, Glenn Morris wrote: > Glenn Morris wrote: > > <garbled message with headers in body> > > Dammit, why does Gnus do that to me sometimes when I edit a draft then > send it? Anyone else ever bothered by this? No, I've never seen this happen for me (and I don't recall reports about it neither) and I edit and send drafts quite often. Ideas anyone? > I've always suspected it may be some Gnus/VM interaction with > different settings for some message header separator... Are you saying that you use VM? I don't know how VM may interact here as I don't know it. Do you have a Gcc-ed copy of the message or maybe Joakim could provide his copy? It might provide some glue to see which headers were still inserted correctly and which not (I suspect that the mailing list software may change the order of the headers). Also, please show us your settings, especially how you insert X-Spook, X-Hue, X-Attribution, X-Detected-Kernel, and User-Agent. Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: gnus inserts headers in body 2007-08-26 7:45 ` gnus inserts headers in body Reiner Steib @ 2007-08-27 1:32 ` Glenn Morris 2007-08-27 5:11 ` David Kastrup 0 siblings, 1 reply; 67+ messages in thread From: Glenn Morris @ 2007-08-27 1:32 UTC (permalink / raw) To: Gnus; +Cc: emacs-devel Reiner Steib wrote: > No, I've never seen this happen for me (and I don't recall reports > about it neither) and I edit and send drafts quite often. Ideas > anyone? It has happened to me several times. >> I've always suspected it may be some Gnus/VM interaction with >> different settings for some message header separator... > > Are you saying that you use VM? I don't know how VM may interact here > as I don't know it. Yes, I use VM as well as Gnus. I have the impression the problem occurs when I: start Gnus, compose a message, save as draft, start VM, do some stuff, return to Gnus, edit draft, send. I realize it was a vague complaint, I'll try to track down more details when I can. It may well be my fault somehow. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: gnus inserts headers in body 2007-08-27 1:32 ` Glenn Morris @ 2007-08-27 5:11 ` David Kastrup 0 siblings, 0 replies; 67+ messages in thread From: David Kastrup @ 2007-08-27 5:11 UTC (permalink / raw) To: Glenn Morris; +Cc: Gnus, emacs-devel Glenn Morris <rgm@gnu.org> writes: > Reiner Steib wrote: > >> No, I've never seen this happen for me (and I don't recall reports >> about it neither) and I edit and send drafts quite often. Ideas >> anyone? > > It has happened to me several times. > >>> I've always suspected it may be some Gnus/VM interaction with >>> different settings for some message header separator... >> >> Are you saying that you use VM? I don't know how VM may interact here >> as I don't know it. > > Yes, I use VM as well as Gnus. I have the impression the problem > occurs when I: start Gnus, compose a message, save as draft, start VM, > do some stuff, return to Gnus, edit draft, send. > > I realize it was a vague complaint, I'll try to track down more > details when I can. It may well be my fault somehow. Perhaps related: News servers have occasionally rejected articles of mine because they consisted of only headers (or something like that). Inserting a blank line after the "--text follows this line--" line has solved this problem when it occured. The strange thing is that this blank line is not always needed. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-25 12:45 ` joakim 2007-08-26 2:08 ` Glenn Morris @ 2007-08-26 14:56 ` Richard Stallman 1 sibling, 0 replies; 67+ messages in thread From: Richard Stallman @ 2007-08-26 14:56 UTC (permalink / raw) To: joakim; +Cc: emacs-devel - In the changelog there will be a placeholder: ------- Merge performed from mtty branch: TODO insert crunched mtty changelog here. ------- If I did this, it would make more work for me, begging people over the next weeks or months to actually do that. I can't afford it. I would like to do it this way so several people can work together on the crunching, and so the merging wont be delayed so people can start find actual functional problems. I already suggested how to do that. In the multi-tty branch, copy its own change unique log entries to a separate file (for each directory). (I believe this has been done.) Then various people can start simplifying those files. Alternatively, those files could be put into the trunk under the name mtty-ChangeLog in each directory. Then we can work on simplifying them even without checking out multi-tty. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-25 4:07 ` Richard Stallman 2007-08-25 12:45 ` joakim @ 2007-08-25 19:12 ` Glenn Morris 2007-08-26 1:08 ` Richard Stallman 1 sibling, 1 reply; 67+ messages in thread From: Glenn Morris @ 2007-08-25 19:12 UTC (permalink / raw) To: rms; +Cc: joakim, emacs-devel Richard Stallman wrote: > The CVS change logs are insufficient because they do not list the > authors' names. They list who checked in the change. This is not related to this issue, but when I check in changes written by someone else, I find it helpful to put their name in the first line of the CVS log entry. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-25 19:12 ` Glenn Morris @ 2007-08-26 1:08 ` Richard Stallman 2007-08-27 5:46 ` Miles Bader 0 siblings, 1 reply; 67+ messages in thread From: Richard Stallman @ 2007-08-26 1:08 UTC (permalink / raw) To: Glenn Morris; +Cc: joakim, emacs-devel This is not related to this issue, but when I check in changes written by someone else, I find it helpful to put their name in the first line of the CVS log entry. It may be related. If we were to adopt such a convention and practice it uniformly, it would eliminate that one reason. I think that there are other issues. For instance, when I make related changes in several files, I put them together in the ChangeLog file. But CVS wouldn't know that. CVS could know that if the files were checked in together, but I can't do that with VC, which is the only way I know. Another issue is that when we make a systematic simple change in lots of files, sometimes we don't bother mentioning them all in ChangeLog. But in the combined CVS log, they would all have to appear individually (right?). Perhaps there are systematic solutions for all these issues. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-26 1:08 ` Richard Stallman @ 2007-08-27 5:46 ` Miles Bader 0 siblings, 0 replies; 67+ messages in thread From: Miles Bader @ 2007-08-27 5:46 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > I think that there are other issues. For instance, when I make > related changes in several files, I put them together in the ChangeLog > file. But CVS wouldn't know that. > > CVS could know that if the files were checked in together, > but I can't do that with VC, which is the only way I know. It looks like Stefan has slowly been extending VC to handle multiple files in various operations, but I don't know if there's a user-interface for this functionality yet. However, I don't think that would help -- AFAIK, CVS has essentially no notion of "multiple file commits", and treats multiple files committed together more or less as if you had committed them separately (with the same log message).[1] If getting rid of ChangeLogs is desirable (and I'm not sure I agree that it is, even though ChangeLogs are a big pain for merging), really the only sane thing to do is switch to a better source-control system than CVS -- and I also think the one that makes sense for Emacs is "git", though for the time being I'm still using arch for my work on emacs.[2] [1] There do seem to be ways you can notice the difference, e.g. commit email messages seem to batch files which are committed together, and perhaps the locking behavior is slightly different, but once things have been committed, I think that information disappears [2] Incidentally, since you (Richard) spend a lot of time in "disconnected" mode, I think you'd personally benefit a lot from something like git -- it would allow you to do all operations (committing, merging, log-checking, etc) operations locally, with easy synchronization once you have access to a network again. -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-24 8:46 ` Leo 2007-08-24 9:03 ` joakim @ 2007-08-24 10:08 ` David Kastrup 2007-08-24 10:41 ` Bootstrap error B. Anyos 1 sibling, 1 reply; 67+ messages in thread From: David Kastrup @ 2007-08-24 10:08 UTC (permalink / raw) To: Leo; +Cc: emacs-devel Leo <sdl.web@gmail.com> writes: > On 2007-08-24 09:01 +0100, joakim@verona.se wrote: >> I am motivated to get the mtty functionality into emacs core, even >> if I wouldn't do the merging this way myself. (I hope the mtty >> history wont be lost this way, that would really not be very good) > > Many people would be grateful for your effort ;) > > Maybe this merging difficulty can be avoided in future. I see one > option for Emacs -- GIT¹. > > Footnotes: > ¹ http://git.or.cz/ But git will not do the kind of ChangeLog munging that is asked for here. On the other hand, git maintains logs and merge history with author/committer distinction (particularly important for merges). One could likely just stop using ChangeLog files at all, or generate them on-demand (for example, to put into the tarball). -- David Kastrup ^ permalink raw reply [flat|nested] 67+ messages in thread
* Bootstrap error 2007-08-24 10:08 ` David Kastrup @ 2007-08-24 10:41 ` B. Anyos 0 siblings, 0 replies; 67+ messages in thread From: B. Anyos @ 2007-08-24 10:41 UTC (permalink / raw) To: emacs-devel Hi, I have a bootstrap error as follows: [...] Compiling /e/Tools/emacs/lisp/emacs-lisp/byte-opt.el In toplevel form: emacs-lisp/byte-opt.el:288:51:Error: Wrong type argument: listp, restp Compiling /e/Tools/emacs/lisp/emacs-lisp/bytecomp.el In toplevel form: emacs-lisp/bytecomp.el:213:38:Error: Wrong type argument: listp, handler Compiling /e/Tools/emacs/lisp/subr.el In toplevel form: subr.el:229:29:Error: Wrong type argument: listp, n Compiling /e/Tools/emacs/lisp/progmodes/cc-mode.el In toplevel form: progmodes/cc-mode.el:170:13:Error: Wrong type argument: listp, source-eval Compiling /e/Tools/emacs/lisp/progmodes/cc-vars.el In toplevel form: progmodes/cc-vars.el:83:19:Error: Wrong type argument: listp, l make[1]: *** [compile-SH] Error 1 make[1]: Leaving directory `/e/Tools/emacs/lisp' make: *** [bootstrap-gmake] Error 2 I've freshly taken sources from CVS. Would anyone solve this? Regards, Bela ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-24 8:01 ` joakim 2007-08-24 8:37 ` Miles Bader 2007-08-24 8:46 ` Leo @ 2007-08-25 4:07 ` Richard Stallman 2 siblings, 0 replies; 67+ messages in thread From: Richard Stallman @ 2007-08-25 4:07 UTC (permalink / raw) To: joakim; +Cc: emacs-devel If a clear and concise algorithm can be presented on how to proceed with this "crunching" I can atempt to do so. Any time you can take multiple entries for a single function and simplify them into one combined entry, if that makes the whole thing simpler, you do it. When you don't see more opportunities to do this, you are done. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-22 15:33 ` Stefan Monnier 2007-08-23 0:19 ` Juri Linkov @ 2007-08-23 20:58 ` Richard Stallman 2007-08-23 21:10 ` Stefan Monnier 1 sibling, 1 reply; 67+ messages in thread From: Richard Stallman @ 2007-08-23 20:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: juri, dann, emacs-devel, karoly, miles > That seems like a daunting task given the size of the logs though... I actually would rather keep the whole uncrunched text. I know it can be found on the branch, but if we insist on putting more than just "merge from branch", then we may as well keep it all. Not crunching changelog makes for a lot more work understanding it in the future. But I don't insist that it be crunched "perfectly". Just to the extent that it makes the text simpler. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-23 20:58 ` Richard Stallman @ 2007-08-23 21:10 ` Stefan Monnier 2007-08-24 16:10 ` Richard Stallman 0 siblings, 1 reply; 67+ messages in thread From: Stefan Monnier @ 2007-08-23 21:10 UTC (permalink / raw) To: rms; +Cc: juri, dann, emacs-devel, karoly, miles >> That seems like a daunting task given the size of the logs though... > I actually would rather keep the whole uncrunched text. I know it can be > found on the branch, but if we insist on putting more than just "merge from > branch", then we may as well keep it all. > Not crunching changelog makes for a lot more work understanding it > in the future. I see no evidence or hint that it would be the case. Stefan ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-23 21:10 ` Stefan Monnier @ 2007-08-24 16:10 ` Richard Stallman 2007-08-24 17:39 ` Stefan Monnier 0 siblings, 1 reply; 67+ messages in thread From: Richard Stallman @ 2007-08-24 16:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: juri, dann, emacs-devel, karoly, miles > Not crunching changelog makes for a lot more work understanding it > in the future. I see no evidence or hint that it would be the case. The bigger the change log is, the harder it is to grasp the changes described. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-24 16:10 ` Richard Stallman @ 2007-08-24 17:39 ` Stefan Monnier 2007-08-25 4:06 ` Richard Stallman 0 siblings, 1 reply; 67+ messages in thread From: Stefan Monnier @ 2007-08-24 17:39 UTC (permalink / raw) To: rms; +Cc: juri, dann, emacs-devel, karoly, miles >> Not crunching changelog makes for a lot more work understanding it >> in the future. > I see no evidence or hint that it would be the case. > The bigger the change log is, the harder it is to grasp > the changes described. I tend to believe the opposite: the description of small changes are easier to understand than description of combined changes. Stefan ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-24 17:39 ` Stefan Monnier @ 2007-08-25 4:06 ` Richard Stallman 2007-08-25 4:22 ` Dan Nicolaescu 0 siblings, 1 reply; 67+ messages in thread From: Richard Stallman @ 2007-08-25 4:06 UTC (permalink / raw) To: Stefan Monnier; +Cc: juri, miles, dann, karoly, emacs-devel I tend to believe the opposite: the description of small changes are easier to understand than description of combined changes. The usual simplification is to replace * foo.c (fooo_bar): Call mumble. ... * foo.c (fooo_bar): New function with * foo.c (fooo_bar): New function since (from the point of view of the trunk) the whole thing is new. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-25 4:06 ` Richard Stallman @ 2007-08-25 4:22 ` Dan Nicolaescu 2007-08-25 19:17 ` Glenn Morris 2007-08-26 1:08 ` Richard Stallman 0 siblings, 2 replies; 67+ messages in thread From: Dan Nicolaescu @ 2007-08-25 4:22 UTC (permalink / raw) To: rms; +Cc: juri, miles, karoly, Stefan Monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > I tend to believe the opposite: the description of small changes are easier > to understand than description of combined changes. > > The usual simplification is to replace > > * foo.c (fooo_bar): Call mumble. > ... > * foo.c (fooo_bar): New function > > with > > * foo.c (fooo_bar): New function > > since (from the point of view of the trunk) the whole > thing is new. Can you please clarify, is crunching the log a blocker for the merge? Or can the merge proceed, add the logs with the dates changed to the date of the merge, and add an entry in FOR-RELEASE that the logs need to be processed? ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-25 4:22 ` Dan Nicolaescu @ 2007-08-25 19:17 ` Glenn Morris 2007-08-26 1:08 ` Richard Stallman 1 sibling, 0 replies; 67+ messages in thread From: Glenn Morris @ 2007-08-25 19:17 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: rms, emacs-devel, juri, karoly, miles, Stefan Monnier Dan Nicolaescu wrote: > Can you please clarify, is crunching the log a blocker for the merge? I would expect that it is, because rms will want the "tidy" logs used for the CVS log entries for the merge. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-25 4:22 ` Dan Nicolaescu 2007-08-25 19:17 ` Glenn Morris @ 2007-08-26 1:08 ` Richard Stallman 1 sibling, 0 replies; 67+ messages in thread From: Richard Stallman @ 2007-08-26 1:08 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: juri, miles, karoly, monnier, emacs-devel Can you please clarify, is crunching the log a blocker for the merge? Yes, because that is needed to make sure it really gets done. If I approved doing the merge first, followed by simplifying the change logs, I expect people would not do the simplification, just as they are not fixing the Emacs 22 bugs. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-22 11:55 ` Miles Bader 2007-08-22 15:33 ` Stefan Monnier @ 2007-08-23 0:45 ` Richard Stallman 2007-08-26 1:05 ` Glenn Morris [not found] ` <200708290403.l7T43TS6023420@oogie-boogie.ics.uci.edu> 3 siblings, 0 replies; 67+ messages in thread From: Richard Stallman @ 2007-08-23 0:45 UTC (permalink / raw) To: Miles Bader; +Cc: juri, dann, karoly, emacs-devel Richard also said he wants the multi-tty changelogs "crunched" before merging -- i.e., essentially replacing many historical entries for a given function/variable by a single entry for it with all the changes (or in the case of a new function/variable, all entries for it except "New function/variable" can be dropped entirely). I'm not sure how this is supposed to work for multiple authors changing the same function.... (one changelog entry per author?). That is one way to do it. That seems like a daunting task given the size of the logs though... I think that anyone here could do it in a few hours. But it doesn't have to be done all by one person. How about checking in a copy of the whole change log (since the branch was forked) in a separate file in each directory? That way, various people can contribute to simplifying it. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-22 11:55 ` Miles Bader 2007-08-22 15:33 ` Stefan Monnier 2007-08-23 0:45 ` Richard Stallman @ 2007-08-26 1:05 ` Glenn Morris 2007-08-26 2:02 ` Glenn Morris ` (2 more replies) [not found] ` <200708290403.l7T43TS6023420@oogie-boogie.ics.uci.edu> 3 siblings, 3 replies; 67+ messages in thread From: Glenn Morris @ 2007-08-26 1:05 UTC (permalink / raw) To: Miles Bader; +Cc: Juri Linkov, Dan Nicolaescu, Karoly Lorentey, Emacs-Devel "Miles Bader" wrote: > Ok, I've put all the changelog info from the arch logs into > "ChangeLog.multi-tty" files in the various emacs directories (on the > multi-tty branch). I split the entries by directory and generally > cleaned up the text. People won't want to hear this, but these ChangeLogs are not very good, IMO. This reflects the original logs, not the way they were combined, I should imagine. Eg I'm looking at the one for lib-src now, trying to clean it up. Many of the changes between the trunk and multi-tty are either not documented, or are not documented very cleanly. I'm finding it necessary to look at the diff between trunk and multi-tty to construct a proper log. Perhaps I have just found a bad example though. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-26 1:05 ` Glenn Morris @ 2007-08-26 2:02 ` Glenn Morris 2007-08-26 22:47 ` Richard Stallman 2007-08-26 14:56 ` Richard Stallman 2007-08-26 15:51 ` Dan Nicolaescu 2 siblings, 1 reply; 67+ messages in thread From: Glenn Morris @ 2007-08-26 2:02 UTC (permalink / raw) To: Dan Nicolaescu, Karoly Lorentey, Emacs-Devel Glenn Morris wrote: > People won't want to hear this, but these ChangeLogs are not very > good, IMO. I have to go further: the lib-src/ChangeLog.multi-tty was bloody awful. I fixed it up as best I can, but with very little understanding of the code it was not easy and can do doubt be improved upon. Many change were totally undocumented, so I have no idea who made them. multi-tty developers: please improve this. I don't think it will take too long for those of you who are familiar with the code. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-26 2:02 ` Glenn Morris @ 2007-08-26 22:47 ` Richard Stallman 0 siblings, 0 replies; 67+ messages in thread From: Richard Stallman @ 2007-08-26 22:47 UTC (permalink / raw) To: Glenn Morris; +Cc: dann, karoly, emacs-devel Thanks for starting to work on the change logs for multi-tty. I have to go further: the lib-src/ChangeLog.multi-tty was bloody awful. I fixed it up as best I can, but with very little understanding of the code it was not easy and can do doubt be improved upon. Many change were totally undocumented, so I have no idea who made them. multi-tty developers: please improve this. I don't think it will take too long for those of you who are familiar with the code. It is a good thing you examined them, so that we know they are incomplete. If I had told people to just go ahead and merge them without paying attention to this, we would not have noticed that these changes were not properly documented in the change logs. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-26 1:05 ` Glenn Morris 2007-08-26 2:02 ` Glenn Morris @ 2007-08-26 14:56 ` Richard Stallman 2007-08-26 15:53 ` Dan Nicolaescu 2007-08-26 15:51 ` Dan Nicolaescu 2 siblings, 1 reply; 67+ messages in thread From: Richard Stallman @ 2007-08-26 14:56 UTC (permalink / raw) To: Glenn Morris; +Cc: juri, dann, emacs-devel, karoly, miles Eg I'm looking at the one for lib-src now, trying to clean it up. Many of the changes between the trunk and multi-tty are either not documented, or are not documented very cleanly. I'm finding it necessary to look at the diff between trunk and multi-tty to construct a proper log. Perhaps I have just found a bad example though. I am surprised that multi-tty required changes in lib-src. Why was that? ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-26 14:56 ` Richard Stallman @ 2007-08-26 15:53 ` Dan Nicolaescu 0 siblings, 0 replies; 67+ messages in thread From: Dan Nicolaescu @ 2007-08-26 15:53 UTC (permalink / raw) To: rms; +Cc: juri, Glenn Morris, miles, karoly, emacs-devel Richard Stallman <rms@gnu.org> writes: > Eg I'm looking at the one for lib-src now, trying to clean it up. Many > of the changes between the trunk and multi-tty are either not > documented, or are not documented very cleanly. I'm finding it > necessary to look at the diff between trunk and multi-tty to construct > a proper log. Perhaps I have just found a bad example though. > > I am surprised that multi-tty required changes in lib-src. > Why was that? For fundamental reasons: emacsclient.c needed to be updated to deal with ttys and handling multiple terminals. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-26 1:05 ` Glenn Morris 2007-08-26 2:02 ` Glenn Morris 2007-08-26 14:56 ` Richard Stallman @ 2007-08-26 15:51 ` Dan Nicolaescu 2 siblings, 0 replies; 67+ messages in thread From: Dan Nicolaescu @ 2007-08-26 15:51 UTC (permalink / raw) To: Glenn Morris Cc: Juri Linkov, Emacs-Devel, Karoly Lorentey, joakim, Miles Bader Glenn Morris <rgm@gnu.org> writes: > "Miles Bader" wrote: > > > Ok, I've put all the changelog info from the arch logs into > > "ChangeLog.multi-tty" files in the various emacs directories (on the > > multi-tty branch). I split the entries by directory and generally > > cleaned up the text. > > Eg I'm looking at the one for lib-src now, trying to clean it up. Many I am working on lisp/ChangeLog.multi-tty, I will check it in when it is done. >From the looks of it, only src/ChangeLog.multi-tty is left. ^ permalink raw reply [flat|nested] 67+ messages in thread
[parent not found: <200708290403.l7T43TS6023420@oogie-boogie.ics.uci.edu>]
[parent not found: <buoy7fvugg5.fsf@dhapc248.dev.necel.com>]
[parent not found: <200708290425.l7T4P4TC023875@oogie-boogie.ics.uci.edu>]
[parent not found: <buosl63uf83.fsf@dhapc248.dev.necel.com>]
[parent not found: <fc339e4a0708282238q7f45a4ffsb11b27b6c1f6701a@mail.gmail.com>]
* Re: merging etc [not found] ` <fc339e4a0708282238q7f45a4ffsb11b27b6c1f6701a@mail.gmail.com> @ 2007-08-29 13:33 ` Juanma Barranquero 2007-09-13 9:31 ` Juanma Barranquero 2007-08-29 16:12 ` Romain Francoise 2007-08-30 7:14 ` Richard Stallman 2 siblings, 1 reply; 67+ messages in thread From: Juanma Barranquero @ 2007-08-29 13:33 UTC (permalink / raw) To: Miles Bader; +Cc: Dan Nicolaescu, emacs-devel On 8/29/07, Miles Bader <miles@gnu.org> wrote: > No doubt some things have broken as a result (I haven't tested it). Ctrl-Z => "Suspending an Emacs running under W32 makes no sense" Gee, Emacs, thanks, I *know*... that's why it used to run iconify-or-deiconify-frame :) Also, I'm seeing a redisplay bug where part of an inactive modeline is left over the fringe after killing the window. Juanma ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-29 13:33 ` Juanma Barranquero @ 2007-09-13 9:31 ` Juanma Barranquero 2007-09-13 9:48 ` Jason Rumney 0 siblings, 1 reply; 67+ messages in thread From: Juanma Barranquero @ 2007-09-13 9:31 UTC (permalink / raw) To: emacs-devel I'm still getting this redisplay bug on Windows. I think it first appeared just after the multi-tty merge. On 8/29/07, Juanma Barranquero <lekktu@gmail.com> wrote: > Also, I'm seeing a redisplay bug where part of an inactive modeline is > left over the fringe after killing the window. A simple recipe: -------- .emacs -------- (setq default-indicate-empty-lines t) ------------------------ C:\> emacs C-x b [RET] ; so we are in *scratch* C-x 2 C-x 0 Juanma ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-09-13 9:31 ` Juanma Barranquero @ 2007-09-13 9:48 ` Jason Rumney 2007-09-13 18:51 ` Glenn Morris 0 siblings, 1 reply; 67+ messages in thread From: Jason Rumney @ 2007-09-13 9:48 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel Juanma Barranquero wrote: > I'm still getting this redisplay bug on Windows. I think it first > appeared just after the multi-tty merge. > > On 8/29/07, Juanma Barranquero <lekktu@gmail.com> wrote: > > >> Also, I'm seeing a redisplay bug where part of an inactive modeline is >> left over the fringe after killing the window. >> The fringe seems to not display any of the bitmaps it should, and seems to not clear properly when there should be a bitmap displayed in that part of the fringe. Can anyone with a recent CVS build on other platforms confirm that the fringe is working properly there so we know whether to focus our search on w32 specific or shared code. There have recently been a few reorganizations of the etc folder - could this have affected the bitmaps that are displayed in the fringe (they used to be defined in the src, but did they get moved to external files at some stage, which have now moved?) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-09-13 9:48 ` Jason Rumney @ 2007-09-13 18:51 ` Glenn Morris 0 siblings, 0 replies; 67+ messages in thread From: Glenn Morris @ 2007-09-13 18:51 UTC (permalink / raw) To: Jason Rumney; +Cc: Juanma Barranquero, emacs-devel Jason Rumney wrote: > The fringe seems to not display any of the bitmaps it should, and > seems to not clear properly when there should be a bitmap displayed > in that part of the fringe. Can anyone with a recent CVS build on > other platforms confirm that the fringe is working properly there so > we know whether to focus our search on w32 specific or shared code. Seems to work fine for me on GNU/Linux. (setq default-indicate-buffer-boundaries 'left) works (setq overflow-newline-into-fringe t) works > There have recently been a few reorganizations of the etc folder - > could this have affected the bitmaps that are displayed in the > fringe (they used to be defined in the src, but did they get moved > to external files at some stage, which have now moved?) The moving around was mostly my doing. I don't think I moved anything relevant to the fringe. The bitmaps are still defined in fringe.c AFAICS. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc [not found] ` <fc339e4a0708282238q7f45a4ffsb11b27b6c1f6701a@mail.gmail.com> 2007-08-29 13:33 ` Juanma Barranquero @ 2007-08-29 16:12 ` Romain Francoise 2007-08-29 16:17 ` Leo 2007-08-30 7:14 ` Richard Stallman 2 siblings, 1 reply; 67+ messages in thread From: Romain Francoise @ 2007-08-29 16:12 UTC (permalink / raw) To: emacs-devel "Miles Bader" <miles@gnu.org> writes: > Ok, the multi-tty branch has been merged into the trunk. Thank you! ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-29 16:12 ` Romain Francoise @ 2007-08-29 16:17 ` Leo 0 siblings, 0 replies; 67+ messages in thread From: Leo @ 2007-08-29 16:17 UTC (permalink / raw) To: emacs-devel On 2007-08-29 17:12 +0100, Romain Francoise wrote: > "Miles Bader" <miles@gnu.org> writes: > >> Ok, the multi-tty branch has been merged into the trunk. > > Thank you! Many thanks. This is the biggest leap after the release of 22.1. -- Leo <sdl.web AT gmail.com> (GPG Key: 9283AA3F) Gnus is one component of the Emacs operating system. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc [not found] ` <fc339e4a0708282238q7f45a4ffsb11b27b6c1f6701a@mail.gmail.com> 2007-08-29 13:33 ` Juanma Barranquero 2007-08-29 16:12 ` Romain Francoise @ 2007-08-30 7:14 ` Richard Stallman 2007-08-30 8:16 ` joakim 2 siblings, 1 reply; 67+ messages in thread From: Richard Stallman @ 2007-08-30 7:14 UTC (permalink / raw) To: Miles Bader; +Cc: dann, emacs-devel Ok, the multi-tty branch has been merged into the trunk. What about documentation? I don't see any changes in NEWS. I assumed, because you thought the branch was ready to merge, that it had the appropriate documentation. We cannot proceed with development without documentation of these new features. Would you please provide the detailed information on new Lisp-level interfaces? ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-30 7:14 ` Richard Stallman @ 2007-08-30 8:16 ` joakim 2007-08-30 12:37 ` Stefan Monnier 0 siblings, 1 reply; 67+ messages in thread From: joakim @ 2007-08-30 8:16 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > Ok, the multi-tty branch has been merged into the trunk. > > What about documentation? I don't see any changes in NEWS. > I assumed, because you thought the branch was ready to merge, > that it had the appropriate documentation. Just to get things started, here is a tentative NEWS entry: ** Emacs now supports several simultaneous display devices. Emacs can now handle frames on several different X displays and terminals simultaneously. Emacsclient has also been extendend to allow specification on which display to use. > > We cannot proceed with development without documentation of these new > features. Would you please provide the detailed information > on new Lisp-level interfaces? -- Joakim Verona ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-30 8:16 ` joakim @ 2007-08-30 12:37 ` Stefan Monnier 2007-08-30 12:57 ` David Kastrup 2007-08-30 20:58 ` Eli Zaretskii 0 siblings, 2 replies; 67+ messages in thread From: Stefan Monnier @ 2007-08-30 12:37 UTC (permalink / raw) To: joakim; +Cc: emacs-devel > Just to get things started, here is a tentative NEWS entry: > ** Emacs now supports several simultaneous display devices. > Emacs can now handle frames on several different X displays and > terminals simultaneously. Emacsclient has also been extendend to allow > specification on which display to use. That's the Emacs-level documentation. We need the Lisp-level doc as well. Stefan ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-30 12:37 ` Stefan Monnier @ 2007-08-30 12:57 ` David Kastrup 2007-08-30 13:02 ` joakim 2007-08-30 20:58 ` Eli Zaretskii 1 sibling, 1 reply; 67+ messages in thread From: David Kastrup @ 2007-08-30 12:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: joakim, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Just to get things started, here is a tentative NEWS entry: > >> ** Emacs now supports several simultaneous display devices. >> Emacs can now handle frames on several different X displays and >> terminals simultaneously. Emacsclient has also been extendend to allow >> specification on which display to use. > > That's the Emacs-level documentation. It is? We don't need to document that environment variables suddenly are session-specific, we don't need to document the relation of sessions to frames to terminals and so on? That some stuff has become frame-local, too? I think that some of those details would better be solved in a different way, but it is not easy to do or judge that if the current choices are not really documented with their user-relevant consequences. > We need the Lisp-level doc as well. That too. But for discussing and/or cleaning the implications of the design, the consequences for the user are of foremost interest, I think. If we can't explain the consequences for the user concisely and understandably, there is a problem with the design. So that is the kind of documentation I would want to see first. If the user-visible consequences are easy to understand and consistent, the documentation for _that_ can stay, and the Lisp level can then try to follow. -- David Kastrup ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-30 12:57 ` David Kastrup @ 2007-08-30 13:02 ` joakim 2007-08-30 19:56 ` Stefan Monnier 2007-08-31 7:36 ` Richard Stallman 0 siblings, 2 replies; 67+ messages in thread From: joakim @ 2007-08-30 13:02 UTC (permalink / raw) To: emacs-devel David Kastrup <dak@gnu.org> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >>> Just to get things started, here is a tentative NEWS entry: >> >>> ** Emacs now supports several simultaneous display devices. >>> Emacs can now handle frames on several different X displays and >>> terminals simultaneously. Emacsclient has also been extendend to allow >>> specification on which display to use. >> >> That's the Emacs-level documentation. > > It is? We don't need to document that environment variables suddenly > are session-specific, we don't need to document the relation of > sessions to frames to terminals and so on? That some stuff has become > frame-local, too? Is that sort of thing normaly documented in NEWS? I thought the purpose of NEWS was to be a somewhat terse overview? > I think that some of those details would better be solved in a > different way, but it is not easy to do or judge that if the current > choices are not really documented with their user-relevant > consequences. > >> We need the Lisp-level doc as well. > > That too. But for discussing and/or cleaning the implications of the > design, the consequences for the user are of foremost interest, I > think. If we can't explain the consequences for the user concisely > and understandably, there is a problem with the design. > > So that is the kind of documentation I would want to see first. If > the user-visible consequences are easy to understand and consistent, > the documentation for _that_ can stay, and the Lisp level can then try > to follow. > > -- > David Kastrup -- Joakim Verona ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-30 13:02 ` joakim @ 2007-08-30 19:56 ` Stefan Monnier 2007-08-31 7:36 ` Richard Stallman 1 sibling, 0 replies; 67+ messages in thread From: Stefan Monnier @ 2007-08-30 19:56 UTC (permalink / raw) To: joakim; +Cc: emacs-devel > Is that sort of thing normaly documented in NEWS? I thought the > purpose of NEWS was to be a somewhat terse overview? It depends. Usually, the NEWS entries are terse indeed, enough for the user to have some idea of what's going on and where to find the rest of the info if needed. In a case such as the multi-tty patches, an important part is the *change* more than the end result: the Emacs and Elisp manuals need to be updated to reflect the resulting behavior, but the NEWS file might need to contain non-trivial descriptions of how things changed. Stefan ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-30 13:02 ` joakim 2007-08-30 19:56 ` Stefan Monnier @ 2007-08-31 7:36 ` Richard Stallman 1 sibling, 0 replies; 67+ messages in thread From: Richard Stallman @ 2007-08-31 7:36 UTC (permalink / raw) To: joakim; +Cc: emacs-devel Is that sort of thing normaly documented in NEWS? I thought the purpose of NEWS was to be a somewhat terse overview? If I am going to update the manual based on NEWS, NEWS has to contain all the information I need in order to do this. At least for now. We could delete some of it later. If someone else updates the manual now, so it need not be done from NEWS, then a more terse entry in NEWS would be adequate. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: merging etc 2007-08-30 12:37 ` Stefan Monnier 2007-08-30 12:57 ` David Kastrup @ 2007-08-30 20:58 ` Eli Zaretskii 1 sibling, 0 replies; 67+ messages in thread From: Eli Zaretskii @ 2007-08-30 20:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: joakim, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Thu, 30 Aug 2007 08:37:33 -0400 > Cc: emacs-devel <emacs-devel@gnu.org> > > > Just to get things started, here is a tentative NEWS entry: > > > ** Emacs now supports several simultaneous display devices. > > Emacs can now handle frames on several different X displays and > > terminals simultaneously. Emacsclient has also been extendend to allow > > specification on which display to use. > > That's the Emacs-level documentation. Actually, it isn't even that. It's basically an announcement of a new feature without any details, and as such, it's almost useless. Joakim, please take a moment to browse through NEWS entries. For each new feature, they mention at least the most important user commands and variables, and any other auxiliary info, like environment variables, that are necessary to at least turn on/off the feature and control its behavior in some basic ways. In CVS, this kind of documentation serves yet another purpose: it is a reminder to update the manual with the expanded version of the documentation. Without such a reminder, chances are we will forget to update the manual when the time comes to release Emacs. If neither the manual nor NEWS have some information about a new feature (and a major feature such as multi-tty), that feature does not exist for all practical purposes, since no one will be able to use it without prolonged study of the sources. Please have a mercy on us! ^ permalink raw reply [flat|nested] 67+ messages in thread
* bootstrap error @ 2016-10-02 19:48 Colin Baxter 2016-10-02 20:22 ` Philipp Stephani 0 siblings, 1 reply; 67+ messages in thread From: Colin Baxter @ 2016-10-02 19:48 UTC (permalink / raw) To: emacs-devel I get a bootstrap Error 255; value as variable is void: blink-cursor-idle-timer. It might be commit e0ac099 since when I revert that commit the error goes away and the build is successful. Colin Baxter ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2016-10-02 19:48 bootstrap error Colin Baxter @ 2016-10-02 20:22 ` Philipp Stephani 2016-10-03 5:25 ` Colin Baxter 0 siblings, 1 reply; 67+ messages in thread From: Philipp Stephani @ 2016-10-02 20:22 UTC (permalink / raw) To: Colin Baxter, emacs-devel [-- Attachment #1: Type: text/plain, Size: 313 bytes --] Colin Baxter <m43cap@yandex.com> schrieb am So., 2. Okt. 2016 um 21:49 Uhr: > > I get a bootstrap Error 255; value as variable is void: > blink-cursor-idle-timer. It might be commit e0ac099 since when I revert > that commit the error goes away and the build is successful. > Whoops, sorry, should be fixed now. [-- Attachment #2: Type: text/html, Size: 668 bytes --] ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2016-10-02 20:22 ` Philipp Stephani @ 2016-10-03 5:25 ` Colin Baxter 0 siblings, 0 replies; 67+ messages in thread From: Colin Baxter @ 2016-10-03 5:25 UTC (permalink / raw) To: Philipp Stephani; +Cc: emacs-devel Hello Philipp, On Sun, Oct 02 2016, Philipp Stephani wrote: > Colin Baxter <m43cap@yandex.com> schrieb am So., 2. Okt. 2016 um 21:49 Uhr: > > I get a bootstrap Error 255; value as variable is void: > blink-cursor-idle-timer. It might be commit e0ac099 since when I revert > that commit the error goes away and the build is successful. > > Whoops, sorry, should be fixed now. Yes, it's fixed now - thank you. ^ permalink raw reply [flat|nested] 67+ messages in thread
* bootstrap error @ 2006-01-25 13:17 Alexander Klimov 2006-01-25 17:46 ` Eli Zaretskii 0 siblings, 1 reply; 67+ messages in thread From: Alexander Klimov @ 2006-01-25 13:17 UTC (permalink / raw) Cc: emacs-devel Hi. During bootstrap of cvs head on cygwin I got well-known DIRENTRY_NONEMPTY error and fixed it with -#ifdef MSDOS +#if defined(MSDOS) || defined(CYGWIN) Unfortunately, bootstrap still fails in a different place: [...] ./temacs --batch --load loadup bootstrap Loading loadup.el (source)... [...] Loading language/utf-8-lang (source)... Loading language/georgian (source)... Loading international/ucs-tables (source)... mv -f emacs.exe bootstrap-emacs.exe mv: cannot stat `emacs.exe': No such file or directory make: *** [bootstrap-emacs.exe] Error 1 May be it is related to the `indian.el' bug problem you are working at... -- Regards, ASK ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-25 13:17 Alexander Klimov @ 2006-01-25 17:46 ` Eli Zaretskii 2006-01-26 10:21 ` Alexander Klimov 0 siblings, 1 reply; 67+ messages in thread From: Eli Zaretskii @ 2006-01-25 17:46 UTC (permalink / raw) Cc: emacs-devel > Date: Wed, 25 Jan 2006 15:17:33 +0200 (IST) > From: Alexander Klimov <alserkli@inbox.ru> > cc: emacs-devel@gnu.org > > ./temacs --batch --load loadup bootstrap > Loading loadup.el (source)... > [...] > Loading language/utf-8-lang (source)... > Loading language/georgian (source)... > Loading international/ucs-tables (source)... > mv -f emacs.exe bootstrap-emacs.exe > mv: cannot stat `emacs.exe': No such file or directory > make: *** [bootstrap-emacs.exe] Error 1 ??? Is this the exact and full fragment of what you see? Did the build indeed try to "mv -f emacs.exe" right after loading ucs-tables/el? You will see in loadup.el that quite a few more Lisp files had to be loaded, and then Emacs should have dumped itself. >From the fragment you've posted, it looks like Emacs died in the middle of loadup--is that true? > May be it is related to the `indian.el' bug problem you are working at... If it is, then try resyncing with the CVS, because that problem is already solved there. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-25 17:46 ` Eli Zaretskii @ 2006-01-26 10:21 ` Alexander Klimov 2006-01-27 13:25 ` Eli Zaretskii 2006-01-27 20:37 ` Eli Zaretskii 0 siblings, 2 replies; 67+ messages in thread From: Alexander Klimov @ 2006-01-26 10:21 UTC (permalink / raw) Cc: emacs-devel On Wed, 25 Jan 2006, Eli Zaretskii wrote: > > ./temacs --batch --load loadup bootstrap > > Loading loadup.el (source)... > > [...] > > Loading language/utf-8-lang (source)... > > Loading language/georgian (source)... > > Loading international/ucs-tables (source)... > > mv -f emacs.exe bootstrap-emacs.exe > > mv: cannot stat `emacs.exe': No such file or directory > > make: *** [bootstrap-emacs.exe] Error 1 > > ??? Is this the exact and full fragment of what you see? Did the > build indeed try to "mv -f emacs.exe" right after loading > ucs-tables/el? Yes, that is way I guessed that it is the same problem as with indian.el. > it looks like Emacs died in the middle of loadup--is that true? Yes and the newest file in the src directory is temacs.exe (that is there is no core dump). > > May be it is related to the `indian.el' bug problem you are working at... > If it is, then try resyncing with the CVS, because that problem is > already solved there. I always update it and ChangeLog has your 2006-01-20 record. I made the following experiments: in loadup.el I commented out ;;(load "international/ucs-tables") and temacs starts to silently die at font-lock ;;(update-coding-systems-internal) same result (font-lock) ;;(load "font-lock") and it goes to Loading mouse (source)... mv -f emacs.exe bootstrap-emacs.exe removing mouse ;;(load "mouse") and Loading language/georgian (source)... Loading indent (source)... Loading window (source)... Loading frame (source)... Loading term/tty-colors (source)... Loading font-core (source)... Loading facemenu (source)... Loading emacs-lisp/syntax (source)... Loading jit-lock (source)... Loading scroll-bar (source)... mv -f emacs.exe bootstrap-emacs.exe mv: cannot stat `emacs.exe': No such file or directory make: *** [bootstrap-emacs.exe] Error 1 I tried to use gdb: $ gdb ./temacs.exe GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) [...] DISPLAY = 127.0.0.1:0.0 TERM = xterm .gdbinit:784: Error in sourced command file: Cannot access memory at address 0x20000004 (gdb) run --batch --load loadup bootstrap [...] Loading language/georgian (source)... Loading international/ucs-tables (source)... Program received signal SIGSEGV, Segmentation fault. 0x610f285f in done () from /usr/bin/cygwin1.dll (gdb) where #0 0x610f285f in done () from /usr/bin/cygwin1.dll #1 0x20ac0000 in bss_sbrk_buffer () #2 0x610db690 in _vfprintf_r () from /usr/bin/cygwin1.dll #3 0x610deb48 in vfprintf () from /usr/bin/cygwin1.dll #4 0x610e81a5 in printf () from /usr/bin/cygwin1.dll #5 0x6108dd7f in _sigfe () from /usr/bin/cygwin1.dll #6 0x007e9f20 in ?? () #7 0x00040000 in ?? () #8 0x20aa0000 in bss_sbrk_buffer () #9 0x00040000 in ?? () #10 0x000343c8 in ?? () #11 0x2014bab1 in obtain (address=0x202999cc, size=548143104) at ralloc.c:315 #12 0x2014bab1 in obtain (address=0x202999cc, size=548012032) at ralloc.c:315 #13 0x2014c7ac in r_alloc_sbrk (size=135168) at ralloc.c:840 #14 0x2014a63b in align (size=3084) at gmalloc.c:461 #15 0x2014b167 in _malloc_internal (size=4096) at gmalloc.c:588 #16 0x2014b1e1 in _malloc_internal (size=1024) at gmalloc.c:763 #17 0x6105340c in malloc () from /usr/bin/cygwin1.dll #18 0x00000400 in ?? () #19 0x00000000 in ?? () from Lisp Backtrace: "make-char-table" "let" "make-translation-table" "set" "let*" "while" "let" "catch" "cl-block-wrapper" "block" "dolist" "let" "eval-buffer" "let" "unwind-protect" "let*" "if" "load-with-code-conversion" "load" "load" 548 Megs seems too large so I take a look on #11: #11 0x2014bab1 in obtain (address=0x202999cc, size=548143104) at ralloc.c:315 315 if ((*real_morecore) (get) != last_heap->end) (gdb) p get $2 = 548143104 (gdb) p last_heap->end $3 = 0x20ac0000 (gdb) p real_morecore $5 = (POINTER (*)()) 0x2014b840 <__default_morecore> (gdb) up #12 0x2014bab1 in obtain (address=0x202999cc, size=548012032) at ralloc.c:315 315 if ((*real_morecore) (get) != last_heap->end) [...] (gdb) up #13 0x2014c7ac in r_alloc_sbrk (size=135168) at ralloc.c:840 840 if (! obtain (address, get)) (gdb) p get $8 = 327680 (gdb) p address $9 = 0x20aa0000 Something is wrong with this: #13 calls obtain(0x20aa0000,327680) but #12 is in obtain(0x202999cc,548012032) I inserted to r_alloc_sbrk get += extra_bytes + page_size; + static unsigned cnt = 0; + fprintf(stderr, "* not found (%d), obtain more space: %d\n", ++cnt, get); if (! obtain (address, get)) return 0; + fprintf(stderr, "* OK\n"); and get the following: Loading language/thai (source)... Loading language/tibetan (source)... * not found (16), obtain more space: 327680 * OK Loading language/vietnamese (source)... Loading language/misc-lang (source)... Loading language/utf-8-lang (source)... Loading language/georgian (source)... Loading international/ucs-tables (source)... * not found (17), obtain more space: 327680 * not found (18), obtain more space: 327680 * not found (19), obtain more space: 327680 [...] * not found (277), obtain more space: 327680 * not found (278), obtain more space: 327680 mv -f emacs.exe bootstrap-emacs.exe Note that there is no real shortage of memory -- the first time there is no `* OK' temacs uses only 13 Mb (accorting to task manager), and there are another ~300 Mb free. Another observation is that even if obtain does not return anything the memory usage in task manager increases after each call (up to 16 Mb after `not found' number 278, that is 10 Kb on average). I also inserted a debug print into obtain(): + fprintf(stderr, "* obtain(%d, %d)\n", address, size); and it is consistent with what was asked: [...] Loading language/tibetan (source)... * not found (16), obtain more space: 327680 * obtain(547815424, 327680) * OK * obtain(548012032, 31552) * obtain(548017880, 24) Loading language/vietnamese (source)... * obtain(548018120, 24) Loading language/misc-lang (source)... * obtain(548018120, 24) Loading language/utf-8-lang (source)... * obtain(548018120, 24) Loading language/georgian (source)... * obtain(548018120, 24) Loading international/ucs-tables (source)... * not found (17), obtain more space: 327680 * obtain(548012032, 327680) * not found (18), obtain more space: 327680 * obtain(548012032, 327680) [...] so the backtrace was screwed up. I made yet another experiment -- add printout to each return in obtain() to check what is the reason of no `* OK' and it looks like obtain just not return at all. This is what I added: obtain (address, size) [...] + fprintf(stderr, "* obtain(%d, %d), heap = %d\n", address, size, heap); if (! heap) abort (); [...] if ((*real_morecore) ((char *) bloc_start - (char *) new) != new){ + fprintf(stderr, "* cannot make a new heap: %d - %d\n", bloc_start, new); return 0; } [...] if ((*real_morecore) (get) != last_heap->end){ + fprintf(stderr, "* cannot get some extra %d\n", get); return 0; + } [...] + fprintf(stderr, "* obtain() returns %d\n", address); return address; and this is what I get: Loading language/tibetan (source)... * not found (16), obtain more space: 327680 * obtain(547815424, 327680), heap = 539798416 * obtain() returns 547815424 * OK * obtain(548012032, 31552), heap = 539798416 * obtain() returns 548012032 * obtain(548017880, 24), heap = 539798416 * obtain() returns 548017880 Loading language/vietnamese (source)... * obtain(548018120, 24), heap = 539798416 * obtain() returns 548018120 Loading language/misc-lang (source)... * obtain(548018120, 24), heap = 539798416 * obtain() returns 548018120 Loading language/utf-8-lang (source)... * obtain(548018120, 24), heap = 539798416 * obtain() returns 548018120 Loading language/georgian (source)... * obtain(548018120, 24), heap = 539798416 * obtain() returns 548018120 Loading international/ucs-tables (source)... * not found (17), obtain more space: 327680 * obtain(548012032, 327680), heap = 539798416 * not found (18), obtain more space: 327680 * obtain(548012032, 327680), heap = 539798416 [...] * not found (277), obtain more space: 327680 * obtain(548012032, 327680), heap = 539798416 * not found (278), obtain more space: 327680 * obtain(548012032, 327680), heap = 539798416 mv -f emacs.exe bootstrap-emacs.exe mv: cannot stat `emacs.exe': No such file or directory make: *** [bootstrap-emacs.exe] Error 1 Any ideas? BTW, this host has cygwin1.dll 1.5.19-4 (build date 2006-01-20 13:28), gcc 3.4.4, and Win2K. -- Regards, ASK ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-26 10:21 ` Alexander Klimov @ 2006-01-27 13:25 ` Eli Zaretskii 2006-01-28 9:50 ` Alexander Klimov 2006-01-27 20:37 ` Eli Zaretskii 1 sibling, 1 reply; 67+ messages in thread From: Eli Zaretskii @ 2006-01-27 13:25 UTC (permalink / raw) Cc: emacs-devel > Date: Thu, 26 Jan 2006 12:21:01 +0200 (IST) > From: Alexander Klimov <alserkli@inbox.ru> > cc: emacs-devel@gnu.org > > > > Loading international/ucs-tables (source)... > > > mv -f emacs.exe bootstrap-emacs.exe > > > mv: cannot stat `emacs.exe': No such file or directory > > > make: *** [bootstrap-emacs.exe] Error 1 > > > > ??? Is this the exact and full fragment of what you see? Did the > > build indeed try to "mv -f emacs.exe" right after loading > > ucs-tables/el? > > Yes, that is way I guessed that it is the same problem as with > indian.el. But indian.el was loaded already, long ago, at the point where ucs-tables are loaded. So I doubt that this has anything to do with that problem, and it was fixed already anyway. > I tried to use gdb: > > $ gdb ./temacs.exe > GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) It's better to install a newer version of GDB: the backtrace code got improved in the year that passed since that version was built. > Loading international/ucs-tables (source)... > * not found (17), obtain more space: 327680 > * obtain(548012032, 327680), heap = 539798416 > * not found (18), obtain more space: 327680 > * obtain(548012032, 327680), heap = 539798416 > [...] > * not found (277), obtain more space: 327680 > * obtain(548012032, 327680), heap = 539798416 > * not found (278), obtain more space: 327680 > * obtain(548012032, 327680), heap = 539798416 > mv -f emacs.exe bootstrap-emacs.exe > mv: cannot stat `emacs.exe': No such file or directory > make: *** [bootstrap-emacs.exe] Error 1 > > Any ideas? Not yet, but I might have some ideas later. Emacs bootstraps (with MinGW) just fine on my XP box. But if I run temacs inside GDB, I see that loading ucs-tables.el causes `obtain' to be called 3 times with these arguments: Breakpoint 3, obtain (address=0x192c458, size=24) at ralloc.c:255 255 for (heap = last_heap; heap; heap = heap->prev) (gdb) Continuing. Loading international/ucs-tables (source)... Breakpoint 3, obtain (address=0x192c458, size=102512) at ralloc.c:255 255 for (heap = last_heap; heap; heap = heap->prev) (gdb) Continuing. Breakpoint 3, obtain (address=0x193f458, size=102512) at ralloc.c:255 255 for (heap = last_heap; heap; heap = heap->prev) Then I see an error message: Attempt to autoload define-minor-mode while preparing to dump And then it aborts. So I kinda can reproduce your problem, although it doesn't prevent bootstrapping on my system. I will try to find out why this error message is being printed, but note that I don't see any such message during the actual bootstrap, only when I run temacs _after_ bootstrapping. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-27 13:25 ` Eli Zaretskii @ 2006-01-28 9:50 ` Alexander Klimov 2006-01-28 14:01 ` Eli Zaretskii 0 siblings, 1 reply; 67+ messages in thread From: Alexander Klimov @ 2006-01-28 9:50 UTC (permalink / raw) Cc: emacs-devel On Fri, 27 Jan 2006, Eli Zaretskii wrote: > > Yes, that is way I guessed that it is the same problem as with > > indian.el. > > But indian.el was loaded already, long ago, at the point where > ucs-tables are loaded. So I doubt that this has anything to do with > that problem, and it was fixed already anyway. What I wanted to say is that it looks like (what I understand was) the indian.el problem -- some resource is slowly exhausted and so the error manifests itself in some random place afterwards. First I get bootstrap failure at ucs-tables, when I remove ucs-tables I get the same failure at some next module, when I remove that new module -- another one failed. My point was that it looks like ucs-tables or other failed modules have nothing to do with the reason of the error. > Emacs bootstraps (with MinGW) just fine on my XP box. But if I run > temacs inside GDB, I see that loading ucs-tables.el causes `obtain' > to be called 3 times [...] Then I see an error message: > > Attempt to autoload define-minor-mode while preparing to dump > > And then it aborts. So I kinda can reproduce your problem, although > it doesn't prevent bootstrapping on my system. Probably it is some interaction with gdb? In my case obtain was called during bootstrap hundreds of time and in your case it failed after three. > I will try to find out why this error message is being printed, but > note that I don't see any such message during the actual bootstrap, > only when I run temacs _after_ bootstrapping. I have not seen *any* error messages during bootstrap -- it just silently failed. -- Regards, ASK ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-28 9:50 ` Alexander Klimov @ 2006-01-28 14:01 ` Eli Zaretskii 2006-01-29 8:08 ` Alexander Klimov 2006-01-29 17:51 ` Alexander Klimov 0 siblings, 2 replies; 67+ messages in thread From: Eli Zaretskii @ 2006-01-28 14:01 UTC (permalink / raw) Cc: emacs-devel > Date: Sat, 28 Jan 2006 11:50:12 +0200 (IST) > From: Alexander Klimov <ask@eitan.edu> > cc: emacs-devel@gnu.org > > What I wanted to say is that it looks like (what I understand was) the > indian.el problem -- some resource is slowly exhausted and so the > error manifests itself in some random place afterwards. First I get > bootstrap failure at ucs-tables, when I remove ucs-tables I get the > same failure at some next module, when I remove that new module -- > another one failed. My point was that it looks like ucs-tables or > other failed modules have nothing to do with the reason of the error. That is probably so. But I cannot reproduce anything like that on Windows without Cygwin, so you will have to debug this on your machine and tell here your findings. That is the only practical way to debug this. > > Attempt to autoload define-minor-mode while preparing to dump > > > > And then it aborts. So I kinda can reproduce your problem, although > > it doesn't prevent bootstrapping on my system. > > Probably it is some interaction with gdb? I'm not sure. As I explained in a follow-up message, the error message happened because I didn't run temacs with the "bootstrap" argument on the command line. > In my case obtain was called during bootstrap hundreds of time and > in your case it failed after three. There should be no reason for it to call obtain so many times, and moreover, it calls it with the same arguments again and again. Perhaps try downgrading to the previous version of Cygwin--there might be some bug in the latest version. > I have not seen *any* error messages during bootstrap -- it just > silently failed. The silent failure is another puzzle: did it abort? did it exit with a failure indication? Perhaps putting a breakpoint on the lowest-level exit routine you can will shed some light on this. Anyway, thanks for working on this. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-28 14:01 ` Eli Zaretskii @ 2006-01-29 8:08 ` Alexander Klimov 2006-01-29 19:37 ` Eli Zaretskii 2006-01-29 17:51 ` Alexander Klimov 1 sibling, 1 reply; 67+ messages in thread From: Alexander Klimov @ 2006-01-29 8:08 UTC (permalink / raw) Cc: emacs-devel On Sat, 28 Jan 2006, Eli Zaretskii wrote: > Perhaps try downgrading to the previous version of Cygwin--there might > be some bug in the latest version. I have no doubt about it -- I currently use emacs which was built from cvs on 2006-01-16 (before I upgraded cygwin) and the problems with build starts to appear only *after* the last cygwin update. -- Regards, ASK ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-29 8:08 ` Alexander Klimov @ 2006-01-29 19:37 ` Eli Zaretskii 2006-01-30 9:11 ` Alexander Klimov 0 siblings, 1 reply; 67+ messages in thread From: Eli Zaretskii @ 2006-01-29 19:37 UTC (permalink / raw) Cc: emacs-devel > Date: Sun, 29 Jan 2006 10:08:42 +0200 (IST) > From: Alexander Klimov <alserkli@inbox.ru> > cc: emacs-devel@gnu.org > > On Sat, 28 Jan 2006, Eli Zaretskii wrote: > > Perhaps try downgrading to the previous version of Cygwin--there might > > be some bug in the latest version. > > I have no doubt about it -- I currently use emacs which was built from > cvs on 2006-01-16 (before I upgraded cygwin) and the problems with > build starts to appear only *after* the last cygwin update. Then it's probably a good idea to post the information you found on the Cygwin mailing list. Perhaps they will be able to suggest solutions or otherwise shed some light on this problem. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-29 19:37 ` Eli Zaretskii @ 2006-01-30 9:11 ` Alexander Klimov 2006-01-30 11:38 ` Corinna Vinschen 0 siblings, 1 reply; 67+ messages in thread From: Alexander Klimov @ 2006-01-30 9:11 UTC (permalink / raw) Cc: emacs-devel On Sun, 29 Jan 2006, Eli Zaretskii wrote: > > From: Alexander Klimov <alserkli@inbox.ru> > > > > On Sat, 28 Jan 2006, Eli Zaretskii wrote: > > > Perhaps try downgrading to the previous version of Cygwin--there might > > > be some bug in the latest version. I made the following experiment: I installed cygwin 1.5.18-1 and now ./temacs.exe --batch --load loadup bootstrap creates emacs.exe BTW, I have not rebuild temacs because most of build tools are not compatible with the old cygwin dll, e.g., rm produces an error The procedure entry point getline could not be located in the [DLL] cygwin1.dll I reverted back to 19-4 and now temacs again fails with apparent recursion (malloc() from cygwin1.dll calls malloc from temacs). > > I have no doubt about it -- I currently use emacs which was built from > > cvs on 2006-01-16 (before I upgraded cygwin) and the problems with > > build starts to appear only *after* the last cygwin update. > > Then it's probably a good idea to post the information you found on > the Cygwin mailing list. Perhaps they will be able to suggest > solutions or otherwise shed some light on this problem. The problem is that I have no idea what to tell them: temacs fails with DLL 1.5.19-4 but dumps emacs with DLL 1.5.18-1 is not a reasonable bug report. Let me put the question differently: what was changed between 18-1 and 19-4 in the DLL (note that .h files are irrelevant since I used temacs built with 19-4). Cygwin gurus, the start of the thread is here <http://lists.gnu.org/archive/html/emacs-devel/2006-01/msg00931.html> -- Regards, ASK ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-30 9:11 ` Alexander Klimov @ 2006-01-30 11:38 ` Corinna Vinschen 0 siblings, 0 replies; 67+ messages in thread From: Corinna Vinschen @ 2006-01-30 11:38 UTC (permalink / raw) Cc: emacs-devel, Eli Zaretskii On Jan 30 11:11, Alexander Klimov wrote: > On Sun, 29 Jan 2006, Eli Zaretskii wrote: > > Then it's probably a good idea to post the information you found on > > the Cygwin mailing list. Perhaps they will be able to suggest > > solutions or otherwise shed some light on this problem. > > The problem is that I have no idea what to tell them: temacs fails > with DLL 1.5.19-4 but dumps emacs with DLL 1.5.18-1 is not a > reasonable bug report. > > Let me put the question differently: what was changed between 18-1 and > 19-4 in the DLL (note that .h files are irrelevant since I used temacs > built with 19-4). > > Cygwin gurus, the start of the thread is here > <http://lists.gnu.org/archive/html/emacs-devel/2006-01/msg00931.html> Sorry, I can't make a lot out of this error report. Please try to nail down the problem somewhat further, for instance, by providing a minimal testcase which allows to reproduce the problem with a minimum of involved code. Since this revolves around malloc, it might be worth to note that two changes to malloc have been made in Cygwin between 1.5.18 and 1.5.19. First, we switched from Doug Lea's malloc implementation version 2.8.0 to 2.8.3, second, due to a reworked mmap implementation, which uses simple VirtualAlloc for private anonymous maps, we lowered the DEFAULT_MMAP_THRESHOLD from 16 Megs to the usual default of 256K. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-28 14:01 ` Eli Zaretskii 2006-01-29 8:08 ` Alexander Klimov @ 2006-01-29 17:51 ` Alexander Klimov 1 sibling, 0 replies; 67+ messages in thread From: Alexander Klimov @ 2006-01-29 17:51 UTC (permalink / raw) Cc: emacs-devel On Sat, 28 Jan 2006, Eli Zaretskii wrote: > That is probably so. But I cannot reproduce anything like that on > Windows without Cygwin, so you will have to debug this on your machine > and tell here your findings. That is the only practical way to debug > this. I added yet another instrumentation: /* Allocate memory from the heap. */ __ptr_t _malloc_internal (size) __malloc_size_t size; { + static unsigned cnt = 0; + fprintf(stderr, " mi[%d %d", ++cnt, size); [...] PROTECT_MALLOC_STATE (1); + fprintf(stderr, " %d]", result); return result; The log is huge, but let see some interesting examples: mi[1 16 mi[2 4096 539860992 ] 539860992 ] // so _malloc_internal can call itself mi[3 128 mi[4 4096 539860992 ] 539860992 ] [...] Loading language/czech (source)... mi[11497 16336 * not found (13), obtain more space: 327680 * obtain(547618816, 327680), heap = 539798432 * obtain() returns 547618816 * OK 547618816] // _malloc_internal can call obtain but obtain does not call back mi[11498 12 539960624] [...] mi[12090 528 547870720] mi[12091 528 547869696] mi[12092 528 mi[12093 4096 //_malloc_internal was called recursively * not found (14), obtain more space: 327680 * obtain(548012032, 327680), heap = 539798432 mi[12094 1024 mi[12095 4096 // and obtain calls _malloc_internal again! * not found (15), obtain more space: 327680 * obtain(548012032, 327680), heap = 539798432 mi[12096 1024 mi[12097 4096 * not found (16), obtain more space: 327680 [...] So, from some point on obtain starts to call _malloc_internal back, futhermore, gdb shows that malloc() from /usr/bin/cygwin1.dll calls malloc from gmalloc.c. -- Regards, ASK ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: bootstrap error 2006-01-26 10:21 ` Alexander Klimov 2006-01-27 13:25 ` Eli Zaretskii @ 2006-01-27 20:37 ` Eli Zaretskii 1 sibling, 0 replies; 67+ messages in thread From: Eli Zaretskii @ 2006-01-27 20:37 UTC (permalink / raw) Cc: emacs-devel > Date: Thu, 26 Jan 2006 12:21:01 +0200 (IST) > From: Alexander Klimov <alserkli@inbox.ru> > cc: emacs-devel@gnu.org > > Loading international/ucs-tables (source)... > * not found (17), obtain more space: 327680 > * obtain(548012032, 327680), heap = 539798416 > * not found (18), obtain more space: 327680 > * obtain(548012032, 327680), heap = 539798416 > [...] > * not found (277), obtain more space: 327680 > * obtain(548012032, 327680), heap = 539798416 > * not found (278), obtain more space: 327680 > * obtain(548012032, 327680), heap = 539798416 > mv -f emacs.exe bootstrap-emacs.exe > mv: cannot stat `emacs.exe': No such file or directory > make: *** [bootstrap-emacs.exe] Error 1 > > Any ideas? BTW, this host has cygwin1.dll 1.5.19-4 (build date > 2006-01-20 13:28), gcc 3.4.4, and Win2K. After some more tinkering, I think I know why the error message about autoloading define-minor-mode doesn't show during bootstrapping. The function eval.c:do_autoload, which issues that message, does this: /* This is to make sure that loadup.el gives a clear picture of what files are preloaded and when. */ if (! NILP (Vpurify_flag)) error ("Attempt to autoload %s while preparing to dump", SDATA (SYMBOL_NAME (funname))); So this message and the resulting abort should only happen when purify-flag is non-nil. However, loadup.el does this: (if (or (equal (nth 3 command-line-args) "bootstrap") (equal (nth 4 command-line-args) "bootstrap") ;; in case CANNOT_DUMP (equal (nth 0 command-line-args) "../src/bootstrap-emacs")) (let ((dir (car load-path))) ;; We'll probably overflow the pure space. (setq purify-flag nil) (setq load-path (list dir (expand-file-name "emacs-lisp" dir) (expand-file-name "language" dir) (expand-file-name "international" dir) (expand-file-name "textmodes" dir))))) So during bootstrap, purify-flag is nil, and the error never happens. So now the question is, why doesn't this work for Cygwin? Doesn't Cygwin support dumping or something? is purify-flag indeed nil during bootstrap of the Cygwin port? or maybe some of your investigations were not in the bootstrap context, so purify-flag was non-nil? And another puzzle: if autoloading define-minor-mode aborts the Cygwin bootstrap, why doesn't that happen earlier, in help.el, for example, which also uses define-minor-mode? Finally, just to make sure we are not chasing a wild goose, could you please see if the message about autoloading define-minor-mode is indeed the reason for the abort? ^ permalink raw reply [flat|nested] 67+ messages in thread
end of thread, other threads:[~2016-10-03 5:25 UTC | newest] Thread overview: 67+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-08-19 3:17 merging etc Miles Bader [not found] ` <200708211523.l7LFNnVl000876@oogie-boogie.ics.uci.edu> [not found] ` <buo3aycknp8.fsf@dhapc248.dev.necel.com> [not found] ` <200708220820.l7M8KbIt026014@oogie-boogie.ics.uci.edu> [not found] ` <fc339e4a0708220237v3b90ec6fwde90eba1ca936e91@mail.gmail.com> 2007-08-22 11:55 ` Miles Bader 2007-08-22 15:33 ` Stefan Monnier 2007-08-23 0:19 ` Juri Linkov 2007-08-23 20:58 ` Richard Stallman 2007-08-24 8:01 ` joakim 2007-08-24 8:37 ` Miles Bader 2007-08-24 8:46 ` Leo 2007-08-24 9:03 ` joakim 2007-08-25 4:07 ` Richard Stallman 2007-08-25 12:45 ` joakim 2007-08-26 2:08 ` Glenn Morris 2007-08-26 2:16 ` gnus inserts headers in body [was Re: merging etc] Glenn Morris 2007-08-26 7:45 ` gnus inserts headers in body Reiner Steib 2007-08-27 1:32 ` Glenn Morris 2007-08-27 5:11 ` David Kastrup 2007-08-26 14:56 ` merging etc Richard Stallman 2007-08-25 19:12 ` Glenn Morris 2007-08-26 1:08 ` Richard Stallman 2007-08-27 5:46 ` Miles Bader 2007-08-24 10:08 ` David Kastrup 2007-08-24 10:41 ` Bootstrap error B. Anyos 2007-08-25 4:07 ` merging etc Richard Stallman 2007-08-23 20:58 ` Richard Stallman 2007-08-23 21:10 ` Stefan Monnier 2007-08-24 16:10 ` Richard Stallman 2007-08-24 17:39 ` Stefan Monnier 2007-08-25 4:06 ` Richard Stallman 2007-08-25 4:22 ` Dan Nicolaescu 2007-08-25 19:17 ` Glenn Morris 2007-08-26 1:08 ` Richard Stallman 2007-08-23 0:45 ` Richard Stallman 2007-08-26 1:05 ` Glenn Morris 2007-08-26 2:02 ` Glenn Morris 2007-08-26 22:47 ` Richard Stallman 2007-08-26 14:56 ` Richard Stallman 2007-08-26 15:53 ` Dan Nicolaescu 2007-08-26 15:51 ` Dan Nicolaescu [not found] ` <200708290403.l7T43TS6023420@oogie-boogie.ics.uci.edu> [not found] ` <buoy7fvugg5.fsf@dhapc248.dev.necel.com> [not found] ` <200708290425.l7T4P4TC023875@oogie-boogie.ics.uci.edu> [not found] ` <buosl63uf83.fsf@dhapc248.dev.necel.com> [not found] ` <fc339e4a0708282238q7f45a4ffsb11b27b6c1f6701a@mail.gmail.com> 2007-08-29 13:33 ` Juanma Barranquero 2007-09-13 9:31 ` Juanma Barranquero 2007-09-13 9:48 ` Jason Rumney 2007-09-13 18:51 ` Glenn Morris 2007-08-29 16:12 ` Romain Francoise 2007-08-29 16:17 ` Leo 2007-08-30 7:14 ` Richard Stallman 2007-08-30 8:16 ` joakim 2007-08-30 12:37 ` Stefan Monnier 2007-08-30 12:57 ` David Kastrup 2007-08-30 13:02 ` joakim 2007-08-30 19:56 ` Stefan Monnier 2007-08-31 7:36 ` Richard Stallman 2007-08-30 20:58 ` Eli Zaretskii -- strict thread matches above, loose matches on Subject: below -- 2016-10-02 19:48 bootstrap error Colin Baxter 2016-10-02 20:22 ` Philipp Stephani 2016-10-03 5:25 ` Colin Baxter 2006-01-25 13:17 Alexander Klimov 2006-01-25 17:46 ` Eli Zaretskii 2006-01-26 10:21 ` Alexander Klimov 2006-01-27 13:25 ` Eli Zaretskii 2006-01-28 9:50 ` Alexander Klimov 2006-01-28 14:01 ` Eli Zaretskii 2006-01-29 8:08 ` Alexander Klimov 2006-01-29 19:37 ` Eli Zaretskii 2006-01-30 9:11 ` Alexander Klimov 2006-01-30 11:38 ` Corinna Vinschen 2006-01-29 17:51 ` Alexander Klimov 2006-01-27 20:37 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.