-
Notifications
You must be signed in to change notification settings - Fork 123
Regexdispatcher #1944
Regexdispatcher #1944
Conversation
73f5c22
to
183d1c6
Compare
@ingwinlu is there possible some cache involved in the docker container? Can i look into the workspace? This issue
is not reproducible on my local debian, the initial case issue should be fixed with the commit dcf7995. |
No, workspace is cleaned before and after every checkout
The workspace is deleted completely for that test case.
It is for me. Always fails. Double check your last commit. Your commit: So maybe try renaming elektra/PluginProcess.chs to Elektra/PluginProcess.chs. |
i see. since i use git on mac that doesn't really differentiate between cases i've totally overlooked that. i guess it was still cached somehow on my debian vm. good catch! |
I will tell the build system the next time i log in. |
Sorry, we both fixed the same problem. Please rebase. |
…fix typechecker dependency delivery with sandbox, fix test order
…n the source folder
@markus2330 here you go finally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Nice PR but it is unclear for me what the Regexdispatcher is for!
- infos/recommends = | ||
- infos/placements = presetstorage | ||
- infos/status = maintained experimental | ||
- infos/metadata = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which metadata is used?
|
||
## Introduction | ||
|
||
A plugin which generates regex-representations of specification keywords for the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Input/output is unclear: which meta data is consumed, which is generated?
|
||
A plugin which generates regex-representations of specification keywords for the | ||
typechecker plugin before saving a configuration specification. Intended to be | ||
mounted before the typechecker plugin. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"before" is misleading: the actual order need to be specified with placements or infos/ordering
|
||
In order to generate regex representations for different specification keywords, mount a configuration specification along with this plugin. | ||
|
||
`kdb mount <specification> spec/<path> <storage plugin to read the specification> regexdispatcher typechecker` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not let the typechecker depend on the regexdispatcher? Or is it usful to use the typechecker without regexdispatcher!
Please describe more clearly why the regexdispatcher is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i will. basically the typechecker can also work without the regexdispatcher for certain metadata like check/long or check/validation or similar which do not need an intermediate translation process.
However something like check/enum/#1=A
, check/enum/#2=B
needs to be translated to the regex A|B
, which the regexdispatcher handles to keep concerns separated.
Furthermore other people may implement similar plugins that translate their own metakeys to regexes (that don't necessarily have to be implemented in haskell) and so i concluded to keep those things separated from the typechecker plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I assumed something like that. But the docu does not say it.
* cabal, the haskell build system, usually bundled with ghc | ||
* augeas, which provides libfa utilized by this plugin | ||
|
||
## Limitations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong section name, you describe features and not limitations here.
* @param plugin a pointer to the plugin | ||
* @param data the pointer to the data | ||
*/ | ||
void elektraPluginProcessSetData (Plugin * handle, void * data) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this serialized and sent to the other process?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is not, the proxied plugins just run in the child process and on linux it seems to share the memory between the parent and the child process. Thus if the child sets any plugin data directly, this would override the plugin data of the parent process, causing the pluginprocess library to fail.
Therefore i store it inside the pluginprocess data structure on the children's side to avoid this problem.
src/plugins/haskell/haskell.c.in
Outdated
@@ -16,6 +16,11 @@ | |||
#include <kdbpluginprocess.h> | |||
#include <stdio.h> | |||
|
|||
// TODO: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for writing the TODO. Having a way to store plugin data is essential.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually i've forgotten to remove this TODO, this is already implemented as i needed it to pass the linux builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even better 👍
find_package (fa) | ||
|
||
if (LIBFA_FOUND) | ||
add_haskell_plugin (regexdispatcher MODULE "RegexDispatcher" SANDBOX_ADD_SOURCES "src/libs/typesystem/libfa") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how are the tests specified?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests are written in C
-- | ||
-- @file | ||
-- | ||
-- @brief Some parsers which are used in the translation process |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not clear to me what the parsers are for.
@@ -0,0 +1,36 @@ | |||
- infos = Information about the regexdispatcher plugin is in keys below | |||
- infos/author = e1528532 <[email protected]> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please write your name.
some very good points you've raised there especially regarding the ordering and the metakeys and the purpose. |
doc/METADATA.ini
Outdated
usedby/plugins = regexdispatcher | ||
description = the generated regex representing the type of check/enum/# and check/enum/multi metakeys | ||
|
||
[elektra/spec/regex/check/range] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some thoughts about the metadata name:
- the elektra prefix does not give information, all meta data is for and from Elektra.
- it should also not start with spec (do not be confused with the namespace).
And wouldn't it be better that we only have a single metadata and the regex is always merged together? Do you need the information of where the regex comes from?
What was the idea of giving this name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right. as the regexdispatcher does all the preprocessing this essentially yields a check/validation keyword in the end all the time, so in that case i don't need further information where it came from i think. i will try that idea out.
@markus2330 as discussed in #160 these few checks are unlikely to every succeed and thus i'd suggest merging it now? as far as i know they don't check any haskell related things anyway. |
thank you! |
Purpose
Calculates regexes for checker plugins for the use with the typechecker, e.g. converting check/range=0-5000 to a regex representation of that range, also supports the enum checks currently.
Checklist
@markus2330 based on the typechecker branch, the question here is how many things i want to support. I'd add the validation keyword as it more or less represents regexes directly but then lets see, i'd like to get back to writing soon. Basically only the src/plugins/regexdispatcher folder is really relevant and it will be easier to see once the prototype is merged to main.