Vcsn issueshttps://gitlab.lre.epita.fr/vcsn/vcsn/-/issues2018-01-01T11:29:33+01:00https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/199labelsets: factor and check2018-01-01T11:29:33+01:00Akim Demaillelabelsets: factor and checkThe relationship between labelsets and gensets is not clear. Sometimes the labelset bounces the function calls to the genset, and sometimes it implements the function although it could have been done in the genset.
Of course this can l...The relationship between labelsets and gensets is not clear. Sometimes the labelset bounces the function calls to the genset, and sometimes it implements the function although it could have been done in the genset.
Of course this can lead to mismatches, and it probably already does: for instance wordset implements its own `compare` (shortlex), but uses the genset's `less` which is not length-aware...https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/184scc: many issues2017-10-31T06:25:48+01:00Akim Demaillescc: many issuesCheck that files for:
- confusion bw num_of_states and states_size
- support of lazy-automata
- returns non-const references
- should rather return a copy with std::move
And check if there are other similar problems elsewhere.Check that files for:
- confusion bw num_of_states and states_size
- support of lazy-automata
- returns non-const references
- should rather return a copy with std::move
And check if there are other similar problems elsewhere.3.0https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/176Fix naming conventions2017-07-25T10:51:02+02:00Akim DemailleFix naming conventionsUse `es` and `e` for expressions, and `xs`, `x` for expansions. Stop using `rs` and `r`, etc.Use `es` and `e` for expressions, and `xs`, `x` for expansions. Stop using `rs` and `r`, etc.3.0https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/173Move to using signed `int`2017-07-25T10:51:02+02:00Akim DemailleMove to using signed `int`Using `unsigned` seems a good idea, but actually, there are plenty of good reasons not to. Check if we don't get faster on `int` transition_t, state_t, etc.Using `unsigned` seems a good idea, but actually, there are plenty of good reasons not to. Check if we don't get faster on `int` transition_t, state_t, etc.3.0https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/172bin: use vcsn configuration2018-04-28T14:15:18+02:00Akim Demaillebin: use vcsn configurationA lot from vcsn.in can be removed: we no longer need to handle `@PYTHON@` etc., `configuration` should do it for us.A lot from vcsn.in can be removed: we no longer need to handle `@PYTHON@` etc., `configuration` should do it for us.3.0https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/167Start using C++172018-04-28T14:12:55+02:00Akim DemailleStart using C++17Let's use 3.0 as a timestamp to move to the newest revision of C++. There are many things that should help
- std::variant/std::any, for instance in Tools to store the arguments
- if/switch with initializationLet's use 3.0 as a timestamp to move to the newest revision of C++. There are many things that should help
- std::variant/std::any, for instance in Tools to store the arguments
- if/switch with initialization3.0Akim DemailleAkim Demaillehttps://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/107is_synchronized_by: speed up?2018-04-28T14:12:57+02:00Akim Demailleis_synchronized_by: speed up?- There is an intermediate unordered_set that should probably be pulled out of the loop
- Is there a way to use the implementation of evaluate, instead of duplicating it partially
- why do we need completeness?- There is an intermediate unordered_set that should probably be pulled out of the loop
- Is there a way to use the implementation of evaluate, instead of duplicating it partially
- why do we need completeness?https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/97experiment with the removal of nullableset2018-04-28T14:12:57+02:00Akim Demailleexperiment with the removal of nullablesetI think it was an error to dedicate a type to LAL. I believe LAL should not exist as a static type, it should only be a dynamic property of being proper. But since that's costly to evaluate, we first need a cache for properties (see #9...I think it was an error to dedicate a type to LAL. I believe LAL should not exist as a static type, it should only be a dynamic property of being proper. But since that's costly to evaluate, we first need a cache for properties (see #96).
- We must not lose performances
- We should save many compilation cyclesSarasvati MoutoucomarapouléSarasvati Moutoucomarapouléhttps://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/83Common bits between weightsets and labelsets2018-04-28T14:12:57+02:00Akim DemailleCommon bits between weightsets and labelsetsThere is code common to both, for instance `power`, but we could also share the variadic `mul`, both currently in the weight_mixin. Maybe we should move it to the labels? And subclass this mixin for weightsets?There is code common to both, for instance `power`, but we could also share the variadic `mul`, both currently in the weight_mixin. Maybe we should move it to the labels? And subclass this mixin for weightsets?https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/82Use clang tools2018-04-28T14:12:57+02:00Akim DemailleUse clang tools- move to systematic use of clang-format
- explore clang-tidy
- enforce this by tests
- move to systematic use of clang-format
- explore clang-tidy
- enforce this by tests
https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/46dyn: handle integral_constant automatically2018-04-28T14:12:57+02:00Akim Demailledyn: handle integral_constant automaticallyCurrently when we need a static integer, we still write the dyn function by hand in `others.cc`.
I believe we could do that automatically.
Currently when we need a static integer, we still write the dyn function by hand in `others.cc`.
I believe we could do that automatically.
https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/38expansion: experiment with multi-letter firsts2018-04-28T14:12:58+02:00Akim Demailleexpansion: experiment with multi-letter firstsWe might be able to be faster (and more readable) if we could enhance our expansions to support label classes (possibly including ranges).
For instance on `[a-z]*`, we compute:
In [3]: vcsn.context('lal_char(a-z), b').expressio...We might be able to be faster (and more readable) if we could enhance our expansions to support label classes (possibly including ranges).
For instance on `[a-z]*`, we compute:
In [3]: vcsn.context('lal_char(a-z), b').expression('[a-z]*').expansion()
Out[3]: <1> + a.[[^]*] + b.[[^]*] + c.[[^]*] + d.[[^]*] + e.[[^]*] + f.[[^]*] + g.[[^]*] + h.[[^]*] + i.[[^]*] + j.[[^]*] + k.[[^]*] + l.[[^]*] + m.[[^]*] + n.[[^]*] + o.[[^]*] + p.[[^]*] + q.[[^]*] + r.[[^]*] + s.[[^]*] + t.[[^]*] + u.[[^]*] + v.[[^]*] + w.[[^]*] + x.[[^]*] + y.[[^]*] + z.[[^]*]
There are reasons to hope that the following hypothetical run would be more efficient.
In [3]: vcsn.context('lal_char(a-z), b').expression('[a-z]*').expansion()
Out[3]: <1> + [a-z].[[^]*]
Maybe it would make sense only if we do have support for label classes in our expression (`[^]` is actually output syntactic sugar for `a+b+c+...+z`).
We should try _not_ to kill the current performances we have with single letters though.https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/34universal: modernize2018-04-28T14:12:58+02:00Akim Demailleuniversal: modernizeUniversal produces a plain automaton, it would be nicer to produce a decorated one. Decorators such as determinized_automaton should help. Partition automaton might help too, if it were weighted. Maybe both should be fused.
Also, t...Universal produces a plain automaton, it would be nicer to produce a decorated one. Decorators such as determinized_automaton should help. Partition automaton might help too, if it were weighted. Maybe both should be fused.
Also, there are opportunities to speed it up. Using bit sets for instance.
So, first enter it into score, then improve it.
https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/33getarg: be robust to bool2018-04-28T14:12:58+02:00Akim Demaillegetarg: be robust to boolCurrently we cannot write:
static const auto map = getarg<bool>
{
"zpc version",
{
// name, compact.
{"auto", "regular"},
{"compact", true},
{"regular", fa...Currently we cannot write:
static const auto map = getarg<bool>
{
"zpc version",
{
// name, compact.
{"auto", "regular"},
{"compact", true},
{"regular", false},
}
};
because in the first case the `"regular"` is used to build a `bool` (true, obviously), which is exactly not what it should be.
Instead of using pure boost::variant, we should wrap one with a ctor of our own that does the right thing (and saves the client side from this).
Once done, simplify `zpc.hh`.
https://gitlab.lre.epita.fr/vcsn/vcsn/-/issues/30Too many places for `\e`2018-04-28T14:12:58+02:00Akim DemailleToo many places for `\e`We should revise the way the pretty-printing is done. Currently, we have `vcsn::format` that codes the type of output we want: `latex`, `utf8`, `text`, etc. And then each value set decodes it.
As a result, there are many places wher...We should revise the way the pretty-printing is done. Currently, we have `vcsn::format` that codes the type of output we want: `latex`, `utf8`, `text`, etc. And then each value set decodes it.
As a result, there are many places where we define the empty-word as `\varepsilon`, or `ε`, or `\e`, etc. Maybe we should rather define in `vcsn::format` all these symbols, just like `vcsn::rat::printer` already does, and use it everywhere.
Then we could even offer a means to tune these symbols: they could come from configuration files instead of being hard-coded.