aboutsummaryrefslogtreecommitdiff
path: root/scripts/msgpack-gen.lua
Commit message (Collapse)AuthorAge
* api: rename "msgpack_rpc/defs.h" to "api/private/dispatch.h" and use the ↵Björn Linse2016-08-31
| | | | header generator.
* msgpack-gen: Fix for Lua 5.1. (#4857)Florian Walch2016-06-01
| | | goto statement was only introduced in Lua 5.2.
* api: refactor remote ui to use API dispatch generationBjörn Linse2016-05-27
|
* Update lua client to 0.0.1-24Thiago de Arruda2016-04-13
| | | | | The new version of the lua client uses libmpack as a backend, and some test scripts had to be updated to reflect that.
* Windows: Accept CRLF in msgpack-gen.lua grammar #3226Rui Abreu Ferreira2015-08-24
| | | | - MSVC generates output using Windows newlines (\r\n) instead of (\n).
* msgpack: Replace FUNC_ATTR_DEFERRED by FUNC_ATTR_ASYNCThiago de Arruda2015-08-13
| | | | | | | | | | | API functions exposed via msgpack-rpc now fall into two categories: - async functions, which are executed as soon as the request is parsed - sync functions, which are invoked in nvim main loop when processing the `K_EVENT special key Only a few functions which can be safely executed in any context are marked as async.
* msgpack: coerce Ints to Windows/Buffers/TabpagesThiago de Arruda2015-04-13
| | | | Add conversion checking when generating msgpack handlers.
* macro: Add MAX macro and rename min to MINThiago de Arruda2015-02-16
|
* msgpack-rpc: Allow registration of handlers by other modulesThiago de Arruda2014-12-08
|
* msgpack-rpc: Improve logging of msgpack-rpc messagesThiago de Arruda2014-10-23
| | | | | | | | | | - Expose more logging control from the log.c module(get log stream and omit newlines) - Remove logging from the generated functions in msgpack-gen.lua - Refactor channel.c/helpers.c to log every msgpack-rpc payload using msgpack_object_print(a helper function from msgpack.h) - Remove the api_stringify function, it was only useful for logging msgpack-rpc which is now handled by msgpack_object_print.
* debug: Improve debugging of msgpack-rpc requestsThiago de Arruda2014-10-22
| | | | | | - Add the api_stringify function to display API objects - Use api_stringify to display request arguments and return values in DLOG statements.
* debug: Fix broken DLOG macro callsThiago de Arruda2014-10-22
|
* msgpack-rpc: Allow selective deferral API callsThiago de Arruda2014-10-21
| | | | | | | | | | | | | Since all API functions now run immediately after a msgpack-rpc request is parsed by libuv callbacks, a mechanism was added to override this behavior and allow certain functions to run in Nvim main loop. The mechanism is simple: Any API function tagged with the FUNC_ATTR_DEFERRED (a "dummy" attribute only used by msgpack-gen.lua) will be called when Nvim main loop receives a K_EVENT key. To implement this mechanism it was necessary some restructuration on the msgpack-rpc modules, especially in the msgpack-gen.lua script.
* msgpack-rpc: Create subdirectory for msgpack-rpc modulesThiago de Arruda2014-10-21
| | | | | Create the msgpack_rpc subdirectory and move all modules that deal with msgpack-rpc to it. Also merge msgpack_rpc.c into msgpack_rpc/helpers.c
* deps: Switch lua msgpack library to one that supports 2.0Thiago de Arruda2014-09-16
|
* msgpack-gen: Fix msgpack_rpc_init_function_metadataThiago de Arruda2014-09-16
| | | | The function was broken on release builds
* api metadata: Allow typed container information in api functionsThiago de Arruda2014-09-12
| | | | | | | | Adapt gendeclarations.lua/msgpack-gen.lua to allow the `ArrayOf(...)` and `DictionaryOf(...)` types in function headers. These are simple macros that expand to Array and Dictionary respectively, but the information is kept in the metadata object, which is useful for building clients in statically typed languages.
* api/msgpack-rpc: Refactor metadata object constructionThiago de Arruda2014-09-12
| | | | | | | | | Instead of building all metadata from msgpack-gen.lua, we now merge the generated part with manual information(such as types and features). The metadata is accessible through the api method `vim_get_api_info`. This was done to simplify the generator while also increasing flexibility(by being able to add more metadata)
* api/msgpack-rpc: Refactor msgpack_rpc_helpers.{c,h}Thiago de Arruda2014-09-12
| | | | | | - Move helpers that are specific to API types to api/private/helpers.{c,h} - Include headers with generated declarations - Delete unused macros
* api/msgpack-rpc: Parse type information from api/private/defs.hThiago de Arruda2014-09-12
| | | | | | | Enhance msgpack-gen.lua to extract custom api type codes from the ObjectType enum in api/private/defs.h. The type information is made available from the api metadata and clients can use to correctly serialize/deserialize these types using msgpack EXT type.
* msgpack-rpc: Remove support for integer ids in methodsThiago de Arruda2014-09-12
| | | | | There's no need to have integer and string ids, and since we now fully support msgpack-RPC, support for integer ids was removed.
* msgpack-rpc: Refactor API metadata discovery methodThiago de Arruda2014-09-12
| | | | | | | | | | A new method is now exposed via msgpack-rpc: "get_api_metadata". This method has the same job as the old method '0', it returns an object with API metadata for use by generators. There's one difference in the return value though: instead of returning a string containing another serialized msgpack document, the metadata object is returned directly(a separate deserialization step by clients is not required).
* msgpack-rpc: Move handle_missing_method to msgpack_rpc.cThiago de Arruda2014-09-12
| | | | | Since that function is not automatically generated, it's best to place it in a normal C module
* msgpack-rpc: Refactor initializer and dispatcherThiago de Arruda2014-09-12
| | | | | | | | Use Map(String, rpc_method_handler_fn) for storing/retrieving rpc method handlers in msgpack_rpc_init and msgpack_rpc_dispatch. Also refactor serialization/validation functions in the msgpack_rpc.c/msgpack_rpc_helpers.c modules to accept the new STR and BIN types.
* map/msgpack-rpc: Declare/define maps rpc method handlersThiago de Arruda2014-09-12
| | | | | The new map type uses `String` instances as keys to avoid unnecessary copying to zero-terminated buffers.
* deps: Update to the experimental msgpack v5 branchThiago de Arruda2014-09-12
| | | | | | | | Using msgpack v5 will let nvim be more compatible with msgpack libraries for other platforms. This also replaces "raw" references by "bin" which is the new name for msgpack binary data type
* msgpack-rpc: Accept method names in requestsThiago de Arruda2014-08-29
|
* api/events/msgpack: Insert log statements to improve debuggingThiago de Arruda2014-07-17
| | | | | | Also changed the default log level to INFO so developers won't end up with big log files without asking explicitly(DLOG statements were placed in really "hot" code)
* move assert.h include out of vim.hBrandon Coleman2014-07-09
|
* dispatch function generator: Fix bug in validation/initializationThiago de Arruda2014-07-07
| | | | | | - Initialize variables before validating argument count to remove possibility of freeing uninitialized pointers - Set the error when the argument count validation fails
* MsgPack-RPC dispatch based on function array lookup #864Felipe Oliveira Carvalho2014-07-04
| | | | | | This simplifies the generated msgpack_rpc_dispatch() function, separates the code for each RPC method more clearly and allows easy implementation of alternative dispatching methods (e.g. string method id dispatch).
* channel/msgpack_rpc: Refactor API dispatchingThiago de Arruda2014-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is how API dispatching worked before this commit: - The generated `msgpack_rpc_dispatch` function receives a the `msgpack_packer` argument. - The response is incrementally built while validating/calling the API. - Return values/errors are also packed into the `msgpack_packer` while the final response is being calculated. Now the `msgpack_packer` argument is no longer provided, and the `msgpack_rpc_dispatch` function returns `Object`/`Error` values to `msgpack_rpc_call`, which will use those values to build the response in a single pass. This was done because the new `channel_send_call` function created the possibility of having recursive API invocations, and this wasn't possible when sharing a single `msgpack_sbuffer` across call frames(it was shared implicitly through the `msgpack_packer` instance). Since we only start to build the response when the necessary information has been computed, it's now safe to share a single `msgpack_sbuffer` instance across all channels and API invocations. Some other changes also had to be performed: - Handling of the metadata discover was moved to `msgpack_rpc_call` - Expose more types as subtypes of `Object`, this was required to forward the return value from `msgpack_rpc_dispatch` to `msgpack_rpc_call` - Added more helper macros for casting API types to `Object` any
* channel/msgpack_rpc: Refactor to better split functions across modulesThiago de Arruda2014-06-24
| | | | | Move validation/conversion functions and to msgpack_rpc_helpers to separate those from the functions that are used from the channel module
* build: Fix error in dispatch generator for functions with channel_idThiago de Arruda2014-06-18
|
* Add automatic generation of headersZyX2014-06-02
| | | | | | | | | | | | | | | | | - The 'stripdecls.py' script replaces declarations in all headers by includes to generated headers. `ag '#\s*if(?!ndef NEOVIM_).*((?!#\s*endif).*\n)*#ifdef INCLUDE_GENERATED'` was used for this. - Add and integrate gendeclarations.lua into the build system to generate the required includes. - Add -Wno-unused-function - Made a bunch of old-style definitions ANSI This adds a requirement: all type and structure definitions must be present before INCLUDE_GENERATED_DECLARATIONS-protected include. Warning: mch_expandpath (path.h.generated.h) was moved manually. So far it is the only exception.
* Add --api-metadata command line optionRui Abreu Ferreira2014-06-02
| | | | | - New command line option prints the binary API metadata object and exits
* API: Events: Automatically pass channel ids to API functionsThiago de Arruda2014-05-28
| | | | | The dispatch function generator was customized to allow for API functions to declare a 'channel_id' as first argument.
* API: Events: Return channel id from the API discover requestThiago de Arruda2014-05-26
| | | | | This refactors msgapck_rpc_{dipatch,call} to receive the channel id as argument. Now the discovery request returns the [id, metadata] array.
* Remove hardcoded type names from msgpack-gen.luaThiago de Arruda2014-05-17
| | | | | Except for the `Error *` type, all parameter types are valid identifiers, so reuse that LPeg rule.
* Introduce nvim namespace: Fix build process.Eliseo Martínez2014-05-15
| | | | | | | - Leave src as include dir (for includes to recognize 'nvim/' prefix). - Change subdirectory from src to src/nvim. - Fix msgpack generation. - Fix some other paths to new locations.
* Refactor API types and prototypesThiago de Arruda2014-05-12
| | | | | | | | - Split functions with multiple files in the 'api' subdirectory - Move/Add more types in the 'api/defs.h' header - Add more prototypes - Refactor scripts/msgpack-gen.lua - Move msgpack modules to 'os' subdirectory
* Add `msgpack_rpc_dispatch`/metadata generatorThiago de Arruda2014-04-11
This adds a lua script which parses the contents of 'api.h'. After the api is parsed into a metadata table. After that, it will generate: - A msgpack blob for the metadata table. This msgpack object contains everything scripting engines need to generate their own wrappers for the remote API. - The `msgpack_rpc_dispatch` function, which takes care of validating msgpack requests, converting arguments to C types and passing control to the appropriate 'api.h' function. The result is then serialized back to msgpack and returned to the client. This approach was used because: - It automatically modifies `msgpack_rpc_dispatch` to reflect API changes. - Scripting engines that generate remote call wrappers using the msgpack metadata will also adapt automatically to API changes
generated by cgit (git 2.34.1) at 2025-04-29 23:14:39 +0000