lazy loading support
Closed this issue · 21 comments
This patch generated against the master branch adds lazy loading support.
leoliu writes:
This patch generated against the master branch adds lazy loading support.
http://paste.pocoo.org/show/549239/
Hey, thanks for this, Leo! :-)
I might move part of the docstring into the Pymacs manual, or something.
Would you be kind enough to explain the bit about the pymacs-autoloaded
property? Would not it be sufficient to merely check if the function is
already bound instead of checking (than managing) that property? I
think I'm missing something here.
François
Hi Pinard,
I guess you are right. The reason I used the property was to allow pymacs-autoload to update the definition. But it has a flaw i.e. if you have >= 2 functions autoloaded from the same file each will execute pymacs-load once.
I have re-worked the patch as in http://paste.pocoo.org/raw/549294/
I don't know what is causing error in the following steps:
- Emacs -q
- eval (pymacs-autoload 'osx-getenv "os")
- eval (osx-getenv)
I get this error http://paste.pocoo.org/show/549298
Apparently the error is from infinite looping.
In the following form:
(or (fboundp ',function)
(error "Pymacs autoload failed to define function %s" ',function))
I need a way to check if `function' is from python.
Hi Pinard,
I need to use pymacs-python-reference but it is wrapped in a condition i.e. it might not be defined unless @DEFADVICE_OK@.
Assuming pymacs-python-reference is available, the final patch looks like this:
leoliu
reply@reply.github.com
writes:
In the following form:
(or (fboundp ',function) (error "Pymacs autoload failed to define function %s" ',function))I need a way to check if `function' is from python.
Hello, Leo.
This is not easy. (Or more precisely, it would be easy, but ugly.)
I have a suggestion (untried), I do not if it would be do. Just before
calling pymacs-load, maybe use (fmakunbound ,function) ?
François
P.S. "fmakunbound", what a horribly named function! :-)
P.P.S. I have difficulty reaching GitHub. Presumably, they are still
under this long-lasting DDoS attack. Sigh! The Internet changed so
much... I still remember that computer researchers, which I barely
knew, long ago, were letting me remote-mount whole disks in big
universities, with almost no protection! I miss these times, fairly
hard to imagine now, when everybody was trusting each other. ;-)
Hi, Leo. Me again.
In the traceback you are showing me at http://paste.pocoo.org/show/549298, you unexpectedly underline another Pymacs bug. There is seemingly a limit (I was not aware of) in Python by which a function may not receive more than 255 arguments. free_python should receive a single argument holding a list, instead of a variable flurry of arguments. I guess I might have gone a bit overboard on this one (same for zombie_python), trying to spare characters in the communication protocol. I'll correct this, the next time in this area.
François
Leo, it is a good idea to use pymacs-python-reference! I forgot that I swallowed the ugliness already... OK, here is what I think I'll do: use "fmakunbound" when we do not have DEFADVICE_OK, and your solution otherwise. I'll reformat a bit, add a paragraph in the manual, and commit in a few minutes, for you to see, critic and correct :-). François
Hi, Leo. I just created a branch named "leo", from where you can get two commits. (I have bad interactions with Python mode right now, and have to leave for a few hours, with no time to sort these out.) I'll leave the testing and fine tuning to you if you feel like it. Otherwise, you'll have to wait for me! François
Hi François,
I have tested the `leo' branch, the code is working. Thank you for documenting it nicely in the manual ;)
The interactive specification of the second example is given for
illustrative purpose, as it could be written more simply, as in the
first example.
Since in the examples, we are autoloading a function from a standard python module, the interactive spec is fake, i.e. the python definition of that function has no interactive spec.
May be we can define a simple interactive python function using Pymacs.py and use it instead?
BTW, can one attach non-string interactive spec to python functions in python?
Thanks,
Leo
Also, when I ran rst2html.py on pymacs.rst, it reported two issues:
pymacs.rst:16: (WARNING/2) Field list ends without a blank line; unexpected unindent.
pymacs.rst:783: (ERROR/3) Unexpected indentation.
Hi again, Leo.
OK, I now understand what you meant by fake spec. I think we can indeed attach non-string interactive specs (on the Python side), the manual documents it. For the pymacs.rst errors, I corrected the first, and the second apparently vanished (yet I reformatted the paragraph, so I could have unknowingly "repaired" it? :-).
I'll let sleep the matter a few days, in case other problems or comments pop up, before committing on the main branch. Unless you have some reason to think I should do it sooner? Thanks for your collaboration on this one!
François
Hi François,
It is a good idea to leave it a few days.
Here are some very minor fixes: http://paste.pocoo.org/show/549458
Leo
Oh, a small detail before moving to other things. I rewrote the (or ...) and (and ...) writings as (unless ...) or (when ...), just to be in line with the remainder of Pymacs.py. Yet, I'm aware that (or ...) and (and ...) are faster. I would be tempted to prefer legibility to speed here. On the hand, many people just find (or ...) and (and ...) legible enough. Nothing is clear cut.
No worries. I find them to be equally readable ;)
BTW, the second error:
pymacs.rst:783: (ERROR/3) Unexpected indentation.
is still there. A : is missed.
leoliu
reply@reply.github.com
writes:
BTW, the second error:
pymacs.rst:783: (ERROR/3) Unexpected indentation.
is still there. A : is missed.
Got it! Thanks.
François
P.S. I do not write reST often enough! Org mode is getting me rotten! :-)
Thanks. I now consider this issue done ;)
Yes, orgmode would be nicer to work with from within emacs. Years ago I proposed to Carsten to choose a markup format (ReST or markdown) to export org mode to, and nobody seemed to like that idea very much. I still think they made a mistake here. Either of these two markups have far more mature and reliable exporters than orgmode.
Leo
There is one corner case where pymacs-python-reference returns nil i.e. when a function is defined in .py file using lisp("""[whatever lisp code one pleases]"""). There is a project that does this: https://bitbucket.org/agr/ropemacs/src/6913282b6166/ropemacs/__init__.py#cl-534 At the moment pymacs-autoload cannot autoload those functions. In this case one cannot write (pymacs-autoload 'ropemacs-mode "ropemacs" "rope-").
I wonder if pymacs-python-reference could return something (such as "lisp") for this case.
Leo
Quite unrelated to Pymacs, Leo. Indeed, it is slightly annoying that Org is a bit off stream regarding in-line markup, while for the overall structure, it wanted to build over Outline mode. reST requires quite a machinery to parse, which would have had to be translated in Emacs Lisp I guess, and this could be difficult to achieve efficiently. For Markdown, I do not have enough experience to know, yet it looks simpler and speedier. Both reST and Markdown are kind of heavier to amend, because of the wider base of different applications; presumably that Org wanted to stay more light and free, would the need arise to extend it. Nothing is perfect... Sigh! :-)
Hi, Leo. I'm closing this issue, but still, am saving your note about the corner case you describe, and intend to be ponder it again at some later time. Have nice days.
Sounds good. Thanks.
Hi, Leo. I'm adding the description of the "corner case", above, to the Pymacs manual. There, no chance that your comment gets forever forgotten.