unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Preferred approach to inclusion of data in ELPA package
@ 2023-08-17 13:58 Hugo Thunnissen
  2023-08-17 21:14 ` Philip Kaludercic
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Hugo Thunnissen @ 2023-08-17 13:58 UTC (permalink / raw)
  To: emacs-devel

Hi all,

For my package phpinspect.el I am now looking into the creation of an 
index of PHP's built in functions and classes. I'm considering different 
ways of distributing this dataset, but I'm not entirely sure what would 
be the preferred way. Finding out the signatures/properties of built in 
functions and classes is straightforward: I can generate valid PHP stubs 
for them which can then be parsed an indexed by my package just like any 
other PHP code. What I'm not sure about is what the best way would be to 
distribute this data. Options I'm considering are:

1. Distribute the stubs with the package and parse them each time **when 
the package is loaded**.

2. Parse and index the stubs, then serialize the resulting index into a 
gzipped lisp data file that is checked into version control, and is 
loaded **when the package is loaded**. (BTW, should such a .eld file be 
byte compiled for any reason?)

3. Parse and index the stubs, then serialize the resulting index 
**during compile time**. Either by generating lisp code using a macro, 
or by serializing the index into a .eld file. This guarantees the index 
staying up to date with the contents of the stub files whenever the 
package is compiled.

Some more info: I expect the initial dataset to be a file with about 
2000 stub functions and 200something stub classes, but it will grow as 
PHP grows and as phpinspect starts to cover more of PHP's features (for 
example, constant variables may also be included at some point in the 
near future, growing the index by a bit). I guesstimate that it would 
take less than 300ms to parse a set of files like that on most modern 
hardware, but I don't have the benchmarks to back that up yet.

I'm personally leaning towards option 3 and using a macro during compile 
time, but I could be nudged either way. Which approach would be 
preferable and why? Is there a common practice for things like this?

Thanks,

- Hugo




^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2023-08-30 19:27 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-08-17 13:58 Preferred approach to inclusion of data in ELPA package Hugo Thunnissen
2023-08-17 21:14 ` Philip Kaludercic
2023-08-19 11:26   ` Hugo Thunnissen
2023-08-19 15:51     ` Philip Kaludercic
2023-08-20 19:24       ` Hugo Thunnissen
2023-08-20 20:42         ` Philip Kaludercic
2023-08-29  8:41           ` Hugo Thunnissen
2023-08-30 19:27             ` Philip Kaludercic
2023-08-20 13:30 ` sbaugh
2023-08-20 17:47   ` Hugo Thunnissen
2023-08-20 19:43     ` Hugo Thunnissen
2023-08-20 22:59 ` Dmitry Gutov

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).