* Re: (require ...) and file dependencies. [not found] <mailman.16796.1419723800.1147.help-gnu-emacs@gnu.org> @ 2014-12-28 0:22 ` Stefan Monnier 2015-01-03 14:04 ` Oleksandr Gavenko 2015-01-03 14:30 ` Oleksandr Gavenko 2015-01-03 2:12 ` Emanuel Berg 1 sibling, 2 replies; 11+ messages in thread From: Stefan Monnier @ 2014-12-28 0:22 UTC (permalink / raw) To: help-gnu-emacs > They may fixed by: > > (eval-when-compile > (defvar ...)) No, it's fixed with (defvar <foo>) Siuch (defvar <foo>) declarations (i.e. without an initial value) are annotations for the *compiler*, so you don't want to pas them to the `eval'uator (hence you don't want to wrap them in `eval-when-compile'). The fact that they also work when wrapped in `eval-when-compile' is an accident which might get fixed at any point. > Warning: the function `...' is not known to be defined. For these you have (declare-function ...) > Is that right to use (this is used in CEDET): > > (eval-when-compile > (require 'xxx-mode)) In general, no, this will just change the warnings from "not known to be defined" to "not known to be defined at run-time". But if you need it because the problematic function is actually a macro, then yes, this can be the right thing to do (tho it won't necessarily fix your recursive load). > Seems that proper way to fix issue is by rearranging dependency hierarchy by > breaking dependency cycles, isn't? That's would be The Right Thing to do, yes. > I think that I need to move shared definitions from xxx-mode.el into > xxx-core.el: That's one way, yes. Another is to move the shared definitions to one of the two files (presumably to xxx-update since xxx-mode is the one that should require the other). Stefan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: (require ...) and file dependencies. 2014-12-28 0:22 ` (require ...) and file dependencies Stefan Monnier @ 2015-01-03 14:04 ` Oleksandr Gavenko 2015-01-03 14:30 ` Oleksandr Gavenko 1 sibling, 0 replies; 11+ messages in thread From: Oleksandr Gavenko @ 2015-01-03 14:04 UTC (permalink / raw) To: help-gnu-emacs On 2014-12-28, Stefan Monnier wrote: >> They may fixed by: >> >> (eval-when-compile >> (defvar ...)) > > No, it's fixed with > > (defvar <foo>) > > Siuch (defvar <foo>) declarations (i.e. without an initial value) are > annotations for the *compiler*, so you don't want to pas them to the > `eval'uator (hence you don't want to wrap them in `eval-when-compile'). > The fact that they also work when wrapped in `eval-when-compile' is an > accident which might get fixed at any point. Thanks for tips. I found: >> (eval-when-compile >> (defvar ...)) by grepping some sources. I usually try to check how things done by another before inventing own style. Currently Emacs sources have some occurrences of such code (so I send replay also in private to rise attention). I run: ack -C 4 eval-when-compile # with 4 line context and look to `defvar`. Before showing complete list I put weird code, which seems need to be fixed: lisp/progmodes/sql.el 1391:(eval-when-compile 1392- (defvar sql-mode-ansi-font-lock-keywords) 1393- (setq sql-mode-ansi-font-lock-keywords nil)) Here strange comment and strange conditional defvar: lisp/progmodes/verilog-mode.el 8407:(eval-when-compile 8408- ;; Prevent compile warnings; these are let's, not globals 8409: ;; Do not remove the eval-when-compile 8410- ;; - we want an error when we are debugging this code if they are refed. 8411- (defvar sigs-in) 8412- (defvar sigs-inout) 8413- (defvar sigs-intf) (defvar sigs-out) (defvar sigs-out-d) (defvar sigs-out-i) (defvar sigs-out-unk) (defvar sigs-temp) ;; These are known to be from other packages and may not be defined (defvar diff-command nil) (defvar vector-skip-list) ;; There are known to be from newer versions of Emacs (defvar create-lockfiles)) 10065:(eval-when-compile 10066- (if (not (boundp 'indent-pt)) 10067- (defvar indent-pt nil "Local used by insert-indent"))) I don't understand Gnus magic for XEmacs: lisp/gnus/gnus-ml.el 87:(eval-when-compile 88- (when (featurep 'xemacs) 89- (defvar gnus-mailing-list-mode-hook) 90- (defvar gnus-mailing-list-mode-on-hook) 91- (defvar gnus-mailing-list-mode-off-hook))) lisp/gnus/gnus-salt.el 103:(eval-when-compile 104- (when (featurep 'xemacs) 105- (defvar gnus-pick-mode-on-hook) 106- (defvar gnus-pick-mode-off-hook))) 342:(eval-when-compile 343- (when (featurep 'xemacs) 344- (defvar gnus-binary-mode-on-hook) 345- (defvar gnus-binary-mode-off-hook))) lisp/gnus/gnus-dired.el 89:(eval-when-compile 90- (when (featurep 'xemacs) 91- (defvar gnus-dired-mode-hook) 92- (defvar gnus-dired-mode-on-hook) 93- (defvar gnus-dired-mode-off-hook))) Seems that this can be fixed by anyone with commit right away: lisp/org/org.el 8477:(eval-when-compile 8478- (defvar org-property-drawer-re)) lisp/org/org-colview.el 752:(eval-when-compile (defvar org-columns-time)) lisp/printing.el 1099:(eval-when-compile 1100- ;; User Interface --- declared here to avoid compiler warnings 1101- (defvar pr-path-style) 1102- (defvar pr-auto-region) 1103- (defvar pr-menu-char-height) -- Best regards! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: (require ...) and file dependencies. 2014-12-28 0:22 ` (require ...) and file dependencies Stefan Monnier 2015-01-03 14:04 ` Oleksandr Gavenko @ 2015-01-03 14:30 ` Oleksandr Gavenko 1 sibling, 0 replies; 11+ messages in thread From: Oleksandr Gavenko @ 2015-01-03 14:30 UTC (permalink / raw) To: help-gnu-emacs On 2014-12-28, Stefan Monnier wrote: >> They may fixed by: >> >> (eval-when-compile >> (defvar ...)) > > No, it's fixed with > > (defvar <foo>) > > Siuch (defvar <foo>) declarations (i.e. without an initial value) are > annotations for the *compiler*, so you don't want to pas them to the > `eval'uator (hence you don't want to wrap them in `eval-when-compile'). > The fact that they also work when wrapped in `eval-when-compile' is an > accident which might get fixed at any point. I check if (defvar <foo>) pollute `load-history` and it is not! So any can safely load libraries with fake `(defvar <foo>)` and then load original library and `<foo>` will refer to place where value or/and doc-string provided! Seems that docs have no any direct words about defvar and load-history. -- Best regards! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: (require ...) and file dependencies. [not found] <mailman.16796.1419723800.1147.help-gnu-emacs@gnu.org> 2014-12-28 0:22 ` (require ...) and file dependencies Stefan Monnier @ 2015-01-03 2:12 ` Emanuel Berg 1 sibling, 0 replies; 11+ messages in thread From: Emanuel Berg @ 2015-01-03 2:12 UTC (permalink / raw) To: help-gnu-emacs Oleksandr Gavenko <gavenkoa@gmail.com> writes: > But what to do with: Warning: the function `...' is > not known to be defined. Yes, use (require '...) for not only the Emacs stuff but also everything you do. Put (provide '...) last and you're all set. > Seems that proper way to fix issue is by rearranging > dependency hierarchy by breaking dependency cycles, > isn't? You are right, *but*, when you put it that way it seems like almost some government-backed scientific endeavor! It is very simple: just constantly arrange the source files so that what is similar is close to each other. E.g., you write A, then you write B, then you write a, ah, that's close to A, let's put it there, so you have A, a, and B, you write b - BAM! - time to make two files: A, a, and B, b. Just make a habit of doing this constantly: arrange, break, provide, require. Don't be afraid to have tons of files, some that might be very short indeed! It is not difficult, so I'm not even going to say "good luck" this time. Or did I... -- underground experts united ^ permalink raw reply [flat|nested] 11+ messages in thread
* (require ...) and file dependencies. @ 2014-12-27 23:42 Oleksandr Gavenko 2014-12-27 23:59 ` Oleksandr Gavenko ` (3 more replies) 0 siblings, 4 replies; 11+ messages in thread From: Oleksandr Gavenko @ 2014-12-27 23:42 UTC (permalink / raw) To: help-gnu-emacs During compilation I got: Warning: reference to free variable Warning: assignment to free variable They may fixed by: (eval-when-compile (defvar ...)) But what to do with: Warning: the function `...' is not known to be defined. I have: xxx-mode.el xxx-update.el and both files mix uses of variables and functions. "xxx-mode.el" have (require 'xxx-update) and designed to be loaded by user. So "xxx-update.el" can't use (require 'xxx-mode) or you get: Error: Recursive `require' for feature `xxx-mode' Is that right to use (this is used in CEDET): (eval-when-compile (require 'xxx-mode)) Seems that proper way to fix issue is by rearranging dependency hierarchy by breaking dependency cycles, isn't? I think that I need to move shared definitions from xxx-mode.el into xxx-core.el: xxx-mode.el: (require 'xxx-core) (require 'xxx-update) xxx-update.el: (require 'xxx-core) I check elisp sources for influence: cc-vars.el cc-defs.el cc-mode.el cedet-devel-load.el so elisp sources usually organise dependency in acyclic graph and provides special loaders. -- Best regards! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: (require ...) and file dependencies. 2014-12-27 23:42 Oleksandr Gavenko @ 2014-12-27 23:59 ` Oleksandr Gavenko 2014-12-28 0:09 ` Dmitry Gutov ` (2 subsequent siblings) 3 siblings, 0 replies; 11+ messages in thread From: Oleksandr Gavenko @ 2014-12-27 23:59 UTC (permalink / raw) To: help-gnu-emacs On 2014-12-28, Oleksandr Gavenko wrote: > Is that right to use (this is used in CEDET): > > (eval-when-compile > (require 'xxx-mode)) My fault - this also leads to "Recursive `require'". Above trick work only if I move (provide 'xxx-mode) from bottom to top of the "'xxx-mode.el". Is that also incorrect way to fix waring when have dependency problems? -- Best regards! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: (require ...) and file dependencies. 2014-12-27 23:42 Oleksandr Gavenko 2014-12-27 23:59 ` Oleksandr Gavenko @ 2014-12-28 0:09 ` Dmitry Gutov [not found] ` <mailman.16797.1419724814.1147.help-gnu-emacs@gnu.org> [not found] ` <mailman.16798.1419725386.1147.help-gnu-emacs@gnu.org> 3 siblings, 0 replies; 11+ messages in thread From: Dmitry Gutov @ 2014-12-28 0:09 UTC (permalink / raw) To: Oleksandr Gavenko, help-gnu-emacs On 12/28/2014 01:42 AM, Oleksandr Gavenko wrote: > But what to do with: > > Warning: the function `...' is not known to be defined. > > I have: > > xxx-mode.el > xxx-update.el > > and both files mix uses of variables and functions. "xxx-mode.el" have > > (require 'xxx-update) > > and designed to be loaded by user. So "xxx-update.el" can't use > > (require 'xxx-mode) > > or you get: > > Error: Recursive `require' for feature `xxx-mode' You can use `declare-function' in this case. And then make sure than the other package is actually loaded at runtime. > Seems that proper way to fix issue is by rearranging dependency hierarchy by > breaking dependency cycles, isn't? That would be even better, of course. ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.16797.1419724814.1147.help-gnu-emacs@gnu.org>]
* Re: (require ...) and file dependencies. [not found] ` <mailman.16797.1419724814.1147.help-gnu-emacs@gnu.org> @ 2014-12-28 0:24 ` Stefan Monnier 0 siblings, 0 replies; 11+ messages in thread From: Stefan Monnier @ 2014-12-28 0:24 UTC (permalink / raw) To: help-gnu-emacs > Above trick work only if I move (provide 'xxx-mode) from bottom to top of the > "'xxx-mode.el". > Is that also incorrect way to fix waring when have dependency problems? It will make you lose some karma, but it's also a workaround that can do the trick. Stefan ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.16798.1419725386.1147.help-gnu-emacs@gnu.org>]
* Re: (require ...) and file dependencies. [not found] ` <mailman.16798.1419725386.1147.help-gnu-emacs@gnu.org> @ 2015-01-03 2:14 ` Emanuel Berg 2015-01-03 14:51 ` Oleksandr Gavenko [not found] ` <mailman.17173.1420296692.1147.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 11+ messages in thread From: Emanuel Berg @ 2015-01-03 2:14 UTC (permalink / raw) To: help-gnu-emacs Dmitry Gutov <dgutov@yandex.ru> writes: >> Seems that proper way to fix issue is by >> rearranging dependency hierarchy by breaking >> dependency cycles, isn't? > > That would be even better, of course. And more pleasant and rewarding to do, as well. Just go with the flow, man :) -- underground experts united ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: (require ...) and file dependencies. 2015-01-03 2:14 ` Emanuel Berg @ 2015-01-03 14:51 ` Oleksandr Gavenko [not found] ` <mailman.17173.1420296692.1147.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 11+ messages in thread From: Oleksandr Gavenko @ 2015-01-03 14:51 UTC (permalink / raw) To: help-gnu-emacs On 2015-01-03, Emanuel Berg wrote: > Dmitry Gutov <dgutov@yandex.ru> writes: > >>> Seems that proper way to fix issue is by >>> rearranging dependency hierarchy by breaking >>> dependency cycles, isn't? >> >> That would be even better, of course. > > And more pleasant and rewarding to do, as well. Just > go with the flow, man :) I fix compilation warnings and errors in wesnoth-mode. It have wesnoth-mode.el and wesnoth-update.el (for generating validation schema and context sensitive completion). wesnoth-update.el uses some core parsing function from wesnoth-mode.el and author define key binding to wesnoth-update.el from wesnoth-mode.el... To fix issues large parts of code must migrate between files and DVCS blame/annotate history was lost in refactoring. That limitation I hate in VCS. So you have to store detailed copy/paste info in commit message or intensively grep and "DVCS update -r rev" to figure out original place of defun to get know who/when and what fixes done with that defun. -- Best regards! ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.17173.1420296692.1147.help-gnu-emacs@gnu.org>]
* Re: (require ...) and file dependencies. [not found] ` <mailman.17173.1420296692.1147.help-gnu-emacs@gnu.org> @ 2015-01-03 17:34 ` Emanuel Berg 0 siblings, 0 replies; 11+ messages in thread From: Emanuel Berg @ 2015-01-03 17:34 UTC (permalink / raw) To: help-gnu-emacs Oleksandr Gavenko <gavenkoa@gmail.com> writes: > That limitation I hate in VCS. So you have to store > detailed copy/paste info in commit message or > intensively grep and "DVCS update -r rev" to figure > out original place of defun to get know who/when and > what fixes done with that defun. Aha, for such a project when many people fiddle with everything, I think my method would bring havoc as the commits would be huge. Better then to divide the code once and for all between the programmers and then all do their part. That will also tell who is programmer, and who is not... -- underground experts united ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-01-03 17:34 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <mailman.16796.1419723800.1147.help-gnu-emacs@gnu.org> 2014-12-28 0:22 ` (require ...) and file dependencies Stefan Monnier 2015-01-03 14:04 ` Oleksandr Gavenko 2015-01-03 14:30 ` Oleksandr Gavenko 2015-01-03 2:12 ` Emanuel Berg 2014-12-27 23:42 Oleksandr Gavenko 2014-12-27 23:59 ` Oleksandr Gavenko 2014-12-28 0:09 ` Dmitry Gutov [not found] ` <mailman.16797.1419724814.1147.help-gnu-emacs@gnu.org> 2014-12-28 0:24 ` Stefan Monnier [not found] ` <mailman.16798.1419725386.1147.help-gnu-emacs@gnu.org> 2015-01-03 2:14 ` Emanuel Berg 2015-01-03 14:51 ` Oleksandr Gavenko [not found] ` <mailman.17173.1420296692.1147.help-gnu-emacs@gnu.org> 2015-01-03 17:34 ` Emanuel Berg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).