[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic loading progress
From: |
Aurélien Aptel |
Subject: |
Re: Dynamic loading progress |
Date: |
Wed, 9 Jul 2014 23:02:52 +0200 |
I've made a github repo of my work so far:
https://github.com/aaptel/emacs-dynamic-module
On Mon, Jul 7, 2014 at 3:19 AM, Stefan Monnier <address@hidden> wrote:
> The `doc' field could simply be changed to be of type Lisp_Object and
> then follow the usual representation used for lambda expressions
I've followed your advice.
a) I've updated the type of the doc field. I'm initializing it to 0 in
the DEFUN macro and I set it to Qnil in defsubr(). I'm not
initializing the field directly to Qnil because the docs reads:
You must not use C initializers for static or global variables unless
the variables are never written once Emacs is dumped. These variables
with initializers are allocated in an area of memory that becomes
read-only (on certain operating systems) as a result of dumping
Emacs. See Pure Storage.
Instead of duplicating the Fsnarf_documentation code for handling
modules I've added a boolean 'module' parameter. If the function
snarfs a module documentation, don't overwrite the global DOC file
path and store a (FILE . OFFSET) cons instead of a simple offset. This
part works correctly.
b) Now, when fetching a function docstring with Fdocumentation, I
check the types and let the existing get_doc_string() handle the field
itself.
It should work but I've ran into a strange problem: the doc field is
set correctly in step a) but the field becomes either an invalid lisp
object or garbage at step b).
I've added debug print statement (using safe_debug_print):
# this is after calling load-module
---
fmod
("/home/knarf/prog/c/emacs/dyn/modules/fmod.doc" . -16)
---
---
fmod-test1
("/home/knarf/prog/c/emacs/dyn/modules/fmod.doc" . -98)
---
---
fmod-test2
("/home/knarf/prog/c/emacs/dyn/modules/fmod.doc" . -125)
---
---
fmod-test3
("/home/knarf/prog/c/emacs/dyn/modules/fmod.doc" . -152)
---
# now calling (documentation 'fmod...)
--Fdocumentation
fmod
#<INVALID_LISP_OBJECT 0x0322a986>
---
--Fdocumentation
fmod-test1
#<INVALID_LISP_OBJECT 0x0322a996>
---
--Fdocumentation
fmod-test2
((keymap #^[nil nil keymap
#^^[3 0 set-mark-comma...
# [garbage]
---
It suspect it has to do with garbage collecting since I have not done
anything special to protect the doc field. I'm not sure how to
proceed.
- Dynamic loading progress, Aurélien Aptel, 2014/07/02
- Re: Dynamic loading progress, Stefan Monnier, 2014/07/03
- Re: Dynamic loading progress, Aurélien Aptel, 2014/07/06
- Re: Dynamic loading progress, Stefan Monnier, 2014/07/06
- Re: Dynamic loading progress,
Aurélien Aptel <=
- Re: Dynamic loading progress, Stefan Monnier, 2014/07/10
- Re: Dynamic loading progress, Aurélien Aptel, 2014/07/10
- Re: Dynamic loading progress, Stefan Monnier, 2014/07/10
- Re: Dynamic loading progress, Aurélien Aptel, 2014/07/11
- Re: Dynamic loading progress, Stefan Monnier, 2014/07/11