2017-05-31 16:26:53 +08:00
|
|
|
*.breakpoint
|
2017-07-29 23:03:34 +08:00
|
|
|
*.data
|
2015-09-28 05:05:04 +08:00
|
|
|
*.dSYM/
|
2017-05-31 16:26:53 +08:00
|
|
|
*.o
|
|
|
|
|
*.out
|
2015-12-20 21:00:07 +08:00
|
|
|
*.pyc
|
2016-03-19 11:07:54 +08:00
|
|
|
*.session.yaml
|
2017-05-31 16:26:53 +08:00
|
|
|
*.so
|
2017-10-08 20:17:00 +08:00
|
|
|
*.swn
|
2017-05-31 16:26:53 +08:00
|
|
|
*.swo
|
|
|
|
|
*.swp
|
|
|
|
|
*~
|
|
|
|
|
.DS_Store
|
2016-06-05 15:48:34 +08:00
|
|
|
.gdb_history
|
2017-05-31 16:26:53 +08:00
|
|
|
.idea
|
|
|
|
|
.ycm_extra_conf.pyc
|
2017-07-29 23:03:34 +08:00
|
|
|
.temp/
|
2016-07-31 20:56:13 +08:00
|
|
|
Testing/
|
2017-07-11 00:17:18 +08:00
|
|
|
build
|
2017-03-06 23:15:20 +08:00
|
|
|
build/
|
2017-12-12 20:34:27 +08:00
|
|
|
release/examples/build
|
2017-01-17 23:46:05 +08:00
|
|
|
cmake-build-*
|
|
|
|
|
cmake/DownloadProject/
|
2017-02-17 23:11:57 +08:00
|
|
|
dist/
|
2017-03-12 10:05:31 +08:00
|
|
|
src/query/frontend/opencypher/generated/
|
2022-07-19 18:28:19 +08:00
|
|
|
src/query/v2/frontend/opencypher/generated/
|
2022-09-07 23:15:32 +08:00
|
|
|
src/parser/opencypher/generated
|
2017-05-31 16:26:53 +08:00
|
|
|
tags
|
|
|
|
|
ve/
|
|
|
|
|
ve3/
|
2017-07-29 23:03:34 +08:00
|
|
|
perf.data*
|
2017-08-04 23:32:13 +08:00
|
|
|
TAGS
|
2017-12-28 23:35:22 +08:00
|
|
|
*.apollo_measurements
|
Add Lisp C++ Preprocessing (LCP)
Summary:
In order to enhance C++ metaprogramming capabilities, a custom
preprocessing step is added before compilation. C++ code may be mixed
with Lisp code in order to generate a complete C++ source code. The
mechanism is hooked into cmake. To notify cmake of .lcp files, `add_lcp`
function in src/CMakeLists.txt needs to be invoked.
The main executable entry point is in tools/lcp, while the source code
is in src/lisp/lcp.lisp
The main goal of LCP is to auto generate class serialization code and
member variable getter functions. This should now be significantly less
error prone, since you cannot forget to serialize a member variable
through this mechanism. Future uses should be generating other repeating
code, such as `Clone` methods or perhaps some debug information.
.lcp files may contain mixed C++ code (enclosed in #>cpp ... cpp<#
blocks) with Common Lisp code.
NOTE: With great power comes great responsibility. Lisp metaprogramming
capabilities are incredibly powerful. To keep the sanity of the team
intact, use Lisp preprocessing only when *really* necessary.
Reviewers: buda, mferencevic, msantl, dgleich, ipaljak, mculinovic, mtomic
Reviewed By: mtomic
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1361
2018-04-27 21:48:30 +08:00
|
|
|
|
|
|
|
|
# Lisp compiled object code
|
|
|
|
|
*.fas
|
|
|
|
|
*.fasl
|
2018-05-02 15:54:28 +08:00
|
|
|
|
2019-05-03 02:53:54 +08:00
|
|
|
# LCP generated C++ files
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
*.lcp.cpp
|
2018-11-07 01:15:55 +08:00
|
|
|
|
2018-10-05 18:37:23 +08:00
|
|
|
src/database/distributed/serialization.hpp
|
2018-11-07 20:41:39 +08:00
|
|
|
src/database/single_node_ha/serialization.hpp
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
src/distributed/bfs_rpc_messages.hpp
|
|
|
|
|
src/distributed/coordination_rpc_messages.hpp
|
|
|
|
|
src/distributed/data_rpc_messages.hpp
|
|
|
|
|
src/distributed/durability_rpc_messages.hpp
|
2018-09-18 21:43:21 +08:00
|
|
|
src/distributed/dynamic_worker_rpc_messages.hpp
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
src/distributed/index_rpc_messages.hpp
|
|
|
|
|
src/distributed/plan_rpc_messages.hpp
|
|
|
|
|
src/distributed/pull_produce_rpc_messages.hpp
|
|
|
|
|
src/distributed/storage_gc_rpc_messages.hpp
|
|
|
|
|
src/distributed/token_sharing_rpc_messages.hpp
|
|
|
|
|
src/distributed/updates_rpc_messages.hpp
|
2022-07-19 18:28:19 +08:00
|
|
|
src/query/v2/frontend/ast/ast.hpp
|
2018-10-04 17:57:23 +08:00
|
|
|
src/query/frontend/ast/ast.hpp
|
2022-09-21 23:26:55 +08:00
|
|
|
src/storage/v3/bindings/ast/ast.hpp
|
2019-03-15 22:58:16 +08:00
|
|
|
src/query/distributed/frontend/ast/ast_serialization.hpp
|
2022-07-19 18:28:19 +08:00
|
|
|
src/query/v2/distributed/frontend/ast/ast_serialization.hpp
|
2018-10-04 21:23:07 +08:00
|
|
|
src/durability/distributed/state_delta.hpp
|
|
|
|
|
src/durability/single_node/state_delta.hpp
|
2018-11-06 18:03:01 +08:00
|
|
|
src/durability/single_node_ha/state_delta.hpp
|
2018-11-22 16:51:58 +08:00
|
|
|
src/query/frontend/semantic/symbol.hpp
|
2022-07-19 18:28:19 +08:00
|
|
|
src/query/v2/frontend/semantic/symbol.hpp
|
2022-09-22 00:25:51 +08:00
|
|
|
src/expr/semantic/symbol.hpp
|
2019-03-15 22:58:16 +08:00
|
|
|
src/query/distributed/frontend/semantic/symbol_serialization.hpp
|
2022-07-19 18:28:19 +08:00
|
|
|
src/query/v2/distributed/frontend/semantic/symbol_serialization.hpp
|
2019-03-15 22:58:16 +08:00
|
|
|
src/query/distributed/plan/ops.hpp
|
2022-07-19 18:28:19 +08:00
|
|
|
src/query/v2/distributed/plan/ops.hpp
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
src/query/plan/operator.hpp
|
2022-07-19 18:28:19 +08:00
|
|
|
src/query/v2/plan/operator.hpp
|
2022-09-21 23:26:55 +08:00
|
|
|
src/parser/opencypher/generated
|
|
|
|
|
src/expr/semantic/symbol.hpp
|
2018-11-12 20:13:21 +08:00
|
|
|
src/raft/log_entry.hpp
|
|
|
|
|
src/raft/raft_rpc_messages.hpp
|
2019-01-31 20:40:17 +08:00
|
|
|
src/raft/snapshot_metadata.hpp
|
2019-03-05 22:02:16 +08:00
|
|
|
src/raft/storage_info_rpc_messages.hpp
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
src/stats/stats_rpc_messages.hpp
|
2018-11-07 01:15:55 +08:00
|
|
|
src/storage/distributed/rpc/concurrent_id_mapper_rpc_messages.hpp
|
2018-09-05 02:30:58 +08:00
|
|
|
src/transactions/distributed/engine_rpc_messages.hpp
|
