tests: Apple clang issues warning on C++11 features
$ cat /tmp/foo.cc
using foo = int;
foo f;
$ clang++ -Wc++11-extensions -c /tmp/foo.cc
/tmp/foo.cc:1:13: warning: alias declarations are a C++11 extension [-Wc++11-extensions]
using foo = int;
^
1 warning generated.
$ clang++ --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
* tests/local.at (AT_COMPILE_CXX): Make sure -std=c++11 is passed when
running glr2.cc. It may be overridden by another flag in CXXFLAGS
afterwards.
avoid using atoi
* cfg.mk: Disable sc_indent as auto indent is too invasive for now.
Enable sc_prohibit_atoi_atof, except where we don't care.
* src/location.c, src/muscle-tab.c: Use strtol instead of atoi.
gnulib: update
To get
commit 7818455627c5e54813ac89924b8b67d0bc869146
Author: Bruno Haible <bruno@clisp.org>
Date: Fri Sep 17 22:22:50 2021 +0200
threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0.
Reported by Brian Inglis via Akim Demaille in
<https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00063.html>.
* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
Cygwin.
c++: use YY_NOEXCEPT where it helps
Suggested by Don Macpherson.
<https://github.com/akimd/bison/issues/80>
* data/skeletons/c++.m4, data/skeletons/glr2.cc,
* data/skeletons/lalr1.cc, data/skeletons/stack.hh: Use YY_NOEXCEPT
where it helps constructors.
glr2.cc: semantic_option: use a symbol
* data/skeletons/c++.m4 (basic_symbol): Add assignment operators.
* data/skeletons/glr2.cc (semantic_option): Replace yytoken, yyvalue
and yylocation by yyla.
glr2.cc: don't publish move ctor to lalr1.cc
These operators were introduced in "c++: add move assignments to the
symbol type" (fdaedc780af0dd678a4f4fa3175a201a553be20a) for glr2.cc.
* data/skeletons/c++.m4: Define them for glr2.cc only.
glr2.cc: simplify semantic_option
* data/skeletons/glr2.cc (semantic_option): Simplify the rule-based
constructor. This shows that it should be easy to use a symbol_kind,
instead of the kind/value/location triple.
glr2.cc: don't pass %parse-param to destroy
I regret that %destructor and %printer give access to the %parse-param
in lalr1.cc, since that prevents them from being implemented as a
simple destructor and operator<<. Let's not repeat the mistake in
glr2.cc. In addition, fixes a name conflict we have currently in
tests 566 568 570 657:
calc.cc:1395:85: error: declaration shadows a field of 'calc::parser' [-Werror,-Wshadow]
void glr_state::destroy (char const* yymsg, calc::parser& yyparser, semantic_value *result, int *count, int *nerrs)
^
calc.hh:441:21: note: previous declaration is here
semantic_value *result;
^
With this commit, the whole test suite passes for glr2.cc.
* data/skeletons/glr2.cc (glr_state::destroy): Don't take the user
arguments.
glr2.cc: kill trailing white spaces
Fixes several calc tests.
Tests 566 568 570 657 still fail because of a name clash when using
%parse-param:
calc.cc:1395:85: error: declaration shadows a field of 'calc::parser' [-Werror,-Wshadow]
void glr_state::destroy (char const* yymsg, calc::parser& yyparser, semantic_value *result, int *count, int *nerrs)
^
calc.hh:441:21: note: previous declaration is here
semantic_value *result;
^
* data/skeletons/glr2.cc: Fix indentation/trailing spaces.
glr2.cc: move state_stack into the unnamed namespace
* data/skeletons/glr2.cc: here.
Prefer `using` to `typedef`, this is C++11.
Use the type alias we introduced.
glr2.cc: move glr_stack and glr_state into the parser class
In order to be able to link several glr2.cc parser together, we cannot
have glr_stack and glr_state be in no namespace. Putting them in the
unnamed namespace is not doable, since we need to fwd declare them in
the parser. Putting them in the specified namespace is not enough
either, since some users would like to be able to put several parsers
in the same name, only differing by the class name.
* data/skeletons/glr2.cc (glr_state, glr_stack): Move into yy::parser.
glr2.cc: put semantic_option into an unnamed namespace
If we link several glr2.cc parsers together, we get linking failures
because of duplicate symbols.
* data/skeletons/glr2.cc (semantic_option::indexIn)
(semantic_option::next): Remove the useless overloads.
glr2.cc: don't publish YY_EXCEPTIONS
We don't need them in the header file.
* data/skeletons/glr2.cc (YY_EXCEPTIONS): Define only in the
implementation file.
* tests/headers.at (Several Parsers): Also check glr2.cc.
c++: demonstrate custom error messages in the examples
Let's use c++/glr to demonstrate custom error messages in C++ (not
just in glr2.cc).
* examples/c++/glr/c++-types.yy (report_syntax_error): New.
* examples/c++/glr/c++-types.test: Adjust.
* examples/c/bistromathic/parse.y: Comment changes.
* tests/local.at (AT_YYERROR_DEFINE(c++)): Use a nicer way to print
the lookakead's name.
glr2.cc: custom error messages
Reported by Tom Shields <thomas.evans.shields@icloud.com>.
<https://lists.gnu.org/r/bug-bison/2021-08/msg00003.html>
* data/skeletons/glr2.cc (context): New.
Use it to generate the error messages.
Add support for custom error messages.
* tests/calc.at: Check support for custom error messages.
glr2.cc: start the transition to using symbol_type
Currently glr2.cc uses three variables/struct members to denote the
symbols' kind (or state), value and location. lalr1.cc has two types
for "complete" symbols: symbol_type and stack_symbol_type. Let's use
that model in glr2.cc too.
For a start use yyla (a symbol_type) to denote the lookahead, instead
of the triple yytoken, yylval and yylloc. This will make easier the
introduction of the "context" subclass, used in parse.error=custom.
It simplifies the code in several places. For instance from:
symbol_kind_type yytoken_current = this->yytoken;]b4_variant_if([[
value_type yylval_current;
]b4_symbol_variant([this->yytoken],
[yylval_current], [move], [this->yylval])], [[
value_type yylval_current = this->yylval;]])[]b4_locations_if([
location_type yylloc_current = this->yylloc;])[
to:
symbol_type yyla_current = std::move (this->yyla);
* data/skeletons/glr2.cc (yytoken, yylval, yylloc): Replace by...
(yyla): this.
Adjust all dependencies.
(yyloc_default): Remove, unused.
* tests/c++.at, tests/glr-regression.at, tests/types.at: C++11 is
required for glr2.cc.
Adjust to changes in glr2.cc.
c++: add move assignments to the symbol type
This will be used in glr2.cc, which requires C++11.
* data/skeletons/c++.m4 (basic_symbol, by_kind): Add move assignment.
c++: avoid using the obsolete names
* data/skeletons/c++.m4: Don't define obsolete identifiers in the case
of glr2.cc. Let's not start with technical debt.
* data/skeletons/glr2.cc, data/skeletons/lalr1.cc,
* data/skeletons/variant.hh: Use token_kind_type, not token_type.
* tests/c++.at, tests/local.at: Use value_type, not semantic_type.
maint: post-release administrivia
* NEWS: Add header line for next release.
* .prev-version: Record previous version.
* cfg.mk (old_NEWS_hash): Auto-update.
portability: don't use strtof
It is not available on HP-UX 11i.
Reported by Larkin Nickle <me@larbob.org>.
<https://lists.gnu.org/r/bug-bison/2021-09/msg00012.html>
Gnulib provides no replacement, but anyway we should be using doubles,
since difftime uses doubles.
* bootstrap.conf: We want portability on stdtod.
* src/counterexample.c: Use double, not float, for time measurements.
yacc: declare yyerror/yylex only when POSIXLY_CORRECT
The recent changes to comply with POSIX are breaking Automake's test
suite.
Reported by Kiyoshi Kanazawa.
<https://lists.gnu.org/r/bug-bison/2021-09/msg00005.html>
To limit the impact of POSIX changes, bind them to $POSIXLY_CORRECT.
Suggested by Karl Berry.
<https://lists.gnu.org/r/bug-bison/2021-09/msg00009.html>
The existing `maintainer-check-posix` Make target checks these
changes.
* src/getargs.h, src/getargs.c (set_yacc): New.
Use it.
* data/skeletons/bison.m4 (b4_posix_if): New.
* data/skeletons/yacc.c (b4_declare_yyerror_and_yylex): Use it.
* doc/bison.texi, tests/local.at: Adjust.
maint: post-release administrivia
* NEWS: Add header line for next release.
* .prev-version: Record previous version.
* cfg.mk (old_NEWS_hash): Auto-update.
maint: post-release administrivia
* NEWS: Add header line for next release.
* .prev-version: Record previous version.
* cfg.mk (old_NEWS_hash): Auto-update.
tests: disable "Multistart reports"
For some reason this test fails on Solaris/x86. But multistart is not
part of 3.8, so we can postpone the debugging of this issue.
Reported by Dagobert Michelsen.
<https://lists.gnu.org/r/bug-bison/2021-08/msg00027.html>
* tests/report.at (Multistart reports): Comment out.
c++: beware of Visual C++ limitations
Contrary to what commit d8cc6b073e2802d871a16dc62418a7eb62ed2216 "c++:
shorten the assertions that check whether tokens are correct"
believed, MS Visual C++'s preprocessor limitation is not on the input
line length, but on the size of the line holding the full C++
statement.
Reported by Vince Huffaker <vince@vincejulie.com>
<https://lists.gnu.org/r/help-bison/2021-08/msg00003.html>
* data/skeletons/variant.hh (_b4_symbol_constructor_define): Hide the
assertion from Visual C++.
tests: don't postprocess stderr with sed
On Solaris, sed throws away the NUL bytes from the stream, even in C
locale. So instead of postprocessing bison's stderr to neutralize
changes in value of `argv[0]`, use an envvar to actually neutralize
variations of `argv[0]` during tests.
Reported by Dagobert Michelsen.
<https://lists.gnu.org/r/bug-bison/2021-08/msg00025.html>
* src/main.c (main): Change `argv[0]` if BISON_PROGRAM_NAME is
defined.
* tests/bison.in: No longer mess with stderr, just pass
the expected BISON_PROGRAM_NAME value.
examples: don't demonstrate multistart, which is not part of 3.8
Besides, for mysterious reasons, this fails on some environment.
Reported by Dagobert Michelsen.
<https://lists.gnu.org/archive/html/bug-bison/2021-08/msg00008.html>
* examples/c/lexcalc/lexcalc.test, examples/c/lexcalc/parse.y,
* examples/c/lexcalc/scan.l: Revert to a single-start example.
glr2.cc: require C++11
Reported by Dagobert Michelsen.
https://lists.gnu.org/r/bug-bison/2021-08/msg00006.html
* m4/bison-cxx-std.m4 (_BISON_CXXSTD_98_snippet): We don't need
vector::data, it was only for glr2.cc, which is C++11 anyway.
(_BISON_CXXSTD_11_snippet): We need vector::data and std::swap on
arrays.
* m4/cxx.m4 (BISON_TEST_FOR_WORKING_CXX_COMPILER): We don't need
vector::data.
* tests/local.at (AT_COMPILE_CXX): Skip when glr2.cc and no support
for C++11.
maint: post-release administrivia
* NEWS: Add header line for next release.
* .prev-version: Record previous version.
* cfg.mk (old_NEWS_hash): Auto-update.
tests: fix incorrect test case
In c2ba260487927a4cdf061fae10fdd1b387ca3d95 ("glr.c: fix signature
when using custom error messages"), I meant to add a test case for C,
not C++. It does not work in C++.
* tests/calc.at: Run for glr.c, not glr.cc.
build: reject C++ compilers that don't support std::vector::data
GCC 4.2 on macOS claims to support C++98, but does not feature it.
input.cc: In member function 'void state_stack::yycompressStack()':
input.cc:1774: error: 'class std::vector<glr_stack_item, std::allocator<glr_stack_item> >' has no member named 'data'
Reported by Christopher Nielsen <mascguy@github.com>.
<https://trac.macports.org/raw-attachment/ticket/59927/bison-test-results-20210811-95b72.log.xz>.
* m4/bison-cxx-std.m4 (_BISON_CXXSTD_98_snippet): Check for it.
* m4/cxx.m4 (BISON_TEST_FOR_WORKING_CXX_COMPILER): Ditto.
build: check for C++ 20 and 2b
C++20 is released.
* configure.ac, m4/bison-cxx-std.m4, tests/atlocal.in,
* tests/local.at: Replace 2a with 20, and add support for 2b.
tests: remove obsolete checks
* tests/atlocal.in: It was an error for tests to depend on gnulib:
they must not, as gnulib would hide portability issues that we want to
catch. So this piece of code is no longer useful, and must not be
useful.
tests: be robust to old versions of xlstproc
Reported by Christopher Nielsen <mascguy@github.com>.
<https://trac.macports.org/raw-attachment/ticket/59927/bison-test-results-20210811-95b72.log.xz>
* tests/report.at (AT_CHECK_HTML): New.
Use it.
c: fix _Noreturn support detection
Reported by Christopher Nielsen <mascguy@github.com>.
<https://trac.macports.org/ticket/59927#comment:59> and
<https://trac.macports.org/ticket/59927#comment:62>.
* data/skeletons/c.m4: Fix typo.
glr.c: fix signature when using custom error messages
Reported by Tom Shields <thomas.evans.shields@icloud.com>.
* data/skeletons/glr.c (yypcontext_location): Fix return type.
* tests/calc.at: Check the case pure, location, custom error messages.
tests: check symbol/token renumbering
In some extreme situations, with lots of useless tokens, Bison was
numbering them incorrectly, which resulted in a broken grammar.
<https://lists.gnu.org/r/bison-patches/2021-03/msg00001.html>
commit a774839ca873d1082f79ba3c4eecc1e242a28ce1.
* tests/regression.at (Useless Tokens): New.
yacc: comply with recent POSIX updates: declare yyerror and yylex
In POSIX Yacc mode, declare yyerror and yylex unless already #defined,
or if YYERROR_IS_DECLARED/YYLEX_IS_DECLARED are defined (for
consistency with Bison's YYSTYPE_IS_DECLARED/YYLTYPE_IS_DECLARED).
See <https://austingroupbugs.net/view.php?id=1388#c5220>.
* data/skeletons/c.m4 (b4_function_declare): Resurect.
(b4_lex_formals): Since we will possibly expose this prototype
in the header, take the prefix into account.
* data/skeletons/yacc.c (b4_declare_yyerror_and_yylex): New.
(b4_shared_declarations): Use it.
* tests/local.at (AT_YACC_IF): New.
When in Yacc mode, set the `yacc` Autotest keyword.
(AT_YYERROR_DECLARE(c)): Don't declare in Yacc mode,
to avoid clashes (since this signature is static).
(AT_YYERROR_DEFINE(c)): Don't define as static in Yacc mode.
* tests/regression.at (Early token definitions with --yacc): Specify
that we are in Yacc mode.
bistromathic: beware of portability issues with readline
In some cases readline emits a trailing spaces after the last
suggestion, which results in errors such as:
```
-( - atan cos exp ln number sin sqrt$
+( - atan cos exp ln number sin sqrt $
```
Reported by Christopher Nielsen <mascguy@github.com>.
<https://trac.macports.org/ticket/59927#comment:48>
<https://trac.macports.org/attachment/ticket/59927/bison-3.7.6-test-10.13.test-suite.log>
* examples/test (run): Add support for -t.
* examples/c/bistromathic/bistromathic.test: Use it.
d: prepare to be able to run LAC tests
Unfortunately it seems to be quite difficult to have "LAC: Exploratory
stack" run for D.
* data/skeletons/lalr1.d: We need File when traces are enabled.
* tests/local.at (AT_YYLEX_DEFINE(d)): New.
* tests/regression.at: Prepare for D, but don't run it, it does not
work.
tests: factor iterating over skeletons
* tests/local.at (AT_FOR_EACH_SKEL): New.
Use where appropriate.
* data/skeletons/lalr1.d: Reject -d.
* tests/input.at, tests/scanner.at: Also check D.
m4: catch suspicions of unevaluated macros
Check in m4's output if there are sequences such as m4_foo or b4_foo,
which are probably resulting from incorrect m4 processing.
It actually already is useful:
- it caught a leaking b4_lac_if leaking from glr.c, where LAC is not
supported, hence b4_lac_if is not defined.
- it also caught references to location.hh in position.hh when
location.hh does not exist.
- while making "Code injection" robust to these new warnings (it is
its very purpose to let b4_canary pass unevaluated), I saw that it
did not check lalr1.d, and when adding lalr1.d, it revealed it did
underquote ocurrences of token value types.
* src/scan-skel.l (macro): New abbreviation.
Use it.
* data/skeletons/glr.c: Don't use b4_lac_if, we don't have it.
* data/skeletons/location.cc: Don't generate position.hh when we don't
generate location.hh.
* data/skeletons/d.m4 (b4_basic_symbol_constructor_define): Fix
underquotation.
* data/skeletons/bison.m4 (b4_canary): New.
* tests/input.at (Code injection): Use it, and check lalr1.d too.
tests: rename AT_YACC_IF as AT_YACC_C_IF
In data/, b4_yacc_if refers to %yacc, not yacc.c.
* tests/local.at (AT_YACC_IF): Rename as...
(AT_YACC_C_IF): this.
examples: modernize the example Makefiles
* examples/c++/Makefile, examples/c++/calc++/Makefile,
* examples/c++/glr/Makefile, examples/c/bistromathic/Makefile,
* examples/c/calc/Makefile, examples/c/glr/Makefile,
* examples/c/lexcalc/Makefile, examples/c/mfcalc/Makefile,
* examples/c/pushcalc/Makefile, examples/c/reccalc/Makefile,
* examples/c/rpcalc/Makefile, examples/d/calc/Makefile,
* examples/d/simple/Makefile, examples/java/calc/Makefile,
* examples/java/simple/Makefile:
Use --html to generate *.html directly.
No longer demonstrate --xml.
No longer show rules for xml to html.
Use --header, not --defines.
Use --graph without specifying the output file now that we
generate *.gv by default.
scan: fix typo in UTF-8 escape
We had:
```
-mbchar ...|\xF0[\x\90-\xBF]([\x80-\xBF]{2})|...
+mbchar ...|\xF0[\x90-\xBF]([\x80-\xBF]{2})|...
```
so a precise sequence that matches the incorrect regex can let NUL
bytes pass through, which triggers an assertion violation downstream.
It is a pity that Flex does not report an error for such input.
Reported by Ahcheong Lee <ahcheong.lee@gmail.com>.
<https://lists.gnu.org/r/bug-bison/2021-04/msg00003.html>
* src/scan-gram.l (mbchar): Fix the bad regex.
* tests/input.at (Invalid inputs): Check that case.
doc: a bit of editing
* doc/bison.texi: Use @samp{...}, not "..." for pieces of code.
Use @samp{...}, not @command{...} for command lines.
Promote %header/--header over %defines/--defines.
Spellcheck.
all: fix confusion between token ctor and symbol ctor
The symbol constructors are genuine constructors. Token constructors
are plain functions that construct tokens.
d: add push parser support
Support the push-pull directive with the options pull, push and both.
Pull remains the default option.
* data/skeletons/d.m4: Add user aliases for the push parser's return
values: PUSH_MORE, ABORT, ACCEPT.
* data/skeletons/lalr1.d: Add push parser support.
* tests/calc.at: Test it.
d: add token constructors support
The user can return from yylex() by calling the Symbol method of the
same name as the TokenKind reported, and adding the parameters for
value and location if necessary. These methods generate compile-time
errors if the parameters are not correlated. Token constructors work
with both %union and api.value.type union.
* data/skeletons/d.m4: Here.
* tests/calc.at: Test it.
d: add api.value.type union support
The union of the values is handled by the backend.
In D, unions can hold classes, structs, etc., so this is more similar
to the C++ api.value.type variant.
* data/skeletons/d.m4, data/skeletons/lalr1.d: Here.
* tests/calc.at, tests/local.at: Test it.
Merge 3.7.6 into master
* maint:
maint: post-release administrivia
version 3.7.6
yacc: fix push parser
tables: fix again the handling of useless tokens
maint: post-release administrivia
* NEWS: Add header line for next release.
* .prev-version: Record previous version.
* cfg.mk (old_NEWS_hash): Auto-update.
Package Details
The above mentioned version is newly released by the upstream project and not yet available as a recipe. Please add this version.
Thanks a lot !
Bellow Changelog from 3.7.6 to 3.8.2:
2021-09-25 Akim Demaille akim.demaille@gmail.com
2021-09-25 Akim Demaille akim.demaille@gmail.com
2021-09-24 Akim Demaille akim.demaille@gmail.com
2021-09-18 Akim Demaille akim.demaille@gmail.com
2021-09-18 Akim Demaille akim.demaille@gmail.com
2021-09-13 Akim Demaille akim.demaille@gmail.com
2021-09-13 Akim Demaille akim.demaille@gmail.com
2021-09-13 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-12 Akim Demaille akim.demaille@gmail.com
2021-09-11 Akim Demaille akim.demaille@gmail.com
2021-09-11 Akim Demaille akim.demaille@gmail.com
2021-09-11 Akim Demaille akim.demaille@gmail.com
2021-09-11 Akim Demaille akim.demaille@gmail.com
2021-09-07 Akim Demaille akim.demaille@gmail.com
2021-09-07 Akim Demaille akim.demaille@gmail.com
2021-09-07 Akim Demaille akim.demaille@gmail.com
2021-09-02 Akim Demaille akim.demaille@gmail.com
2021-09-02 Akim Demaille akim.demaille@gmail.com
2021-09-02 Akim Demaille akim.demaille@gmail.com
2021-08-29 Akim Demaille akim.demaille@gmail.com
2021-08-29 Akim Demaille akim.demaille@gmail.com
2021-08-29 Akim Demaille akim.demaille@gmail.com
2021-08-29 Akim Demaille akim.demaille@gmail.com
2021-08-19 Akim Demaille akim.demaille@gmail.com
2021-08-19 Akim Demaille akim.demaille@gmail.com
2021-08-19 Akim Demaille akim.demaille@gmail.com
2021-08-19 Akim Demaille akim.demaille@gmail.com
2021-08-13 Akim Demaille akim.demaille@gmail.com
2021-08-13 Akim Demaille akim.demaille@gmail.com
2021-08-13 Akim Demaille akim.demaille@gmail.com
2021-08-13 Akim Demaille akim.demaille@gmail.com
2021-08-12 Akim Demaille akim.demaille@gmail.com
2021-08-12 Akim Demaille akim.demaille@gmail.com
2021-08-12 Akim Demaille akim.demaille@gmail.com
2021-08-12 Akim Demaille akim.demaille@gmail.com
2021-08-12 Akim Demaille akim.demaille@gmail.com
2021-08-12 Akim Demaille akim.demaille@gmail.com
2021-08-12 Akim Demaille akim.demaille@gmail.com
2021-08-12 Akim Demaille akim.demaille@gmail.com
2021-08-11 Akim Demaille akim.demaille@gmail.com
2021-08-11 Akim Demaille akim.demaille@gmail.com
2021-08-11 Akim Demaille akim.demaille@gmail.com
2021-08-11 Akim Demaille akim.demaille@gmail.com
2021-08-09 Akim Demaille akim.demaille@gmail.com
2021-08-09 Akim Demaille akim.demaille@gmail.com
2021-08-09 Akim Demaille akim.demaille@gmail.com
2021-08-09 Akim Demaille akim.demaille@gmail.com
2021-08-08 Akim Demaille akim.demaille@gmail.com
2021-08-07 Akim Demaille akim.demaille@gmail.com
2021-08-07 Akim Demaille akim.demaille@gmail.com
2021-08-07 Akim Demaille akim.demaille@gmail.com
2021-08-07 Akim Demaille akim.demaille@gmail.com
2021-08-07 Akim Demaille akim.demaille@gmail.com
2021-08-06 Akim Demaille akim.demaille@gmail.com
2021-08-06 Akim Demaille akim.demaille@gmail.com
2021-08-06 Akim Demaille akim.demaille@gmail.com
2021-08-06 Akim Demaille akim.demaille@gmail.com
2021-08-06 Akim Demaille akim.demaille@gmail.com
2021-08-04 Akim Demaille akim.demaille@gmail.com
2021-08-04 Akim Demaille akim.demaille@gmail.com
2021-08-04 Akim Demaille akim.demaille@gmail.com
2021-08-04 Akim Demaille akim.demaille@gmail.com
2021-08-04 Akim Demaille akim.demaille@gmail.com
2021-08-04 Akim Demaille akim.demaille@gmail.com
2021-08-03 Akim Demaille akim.demaille@gmail.com
2021-08-03 Akim Demaille akim.demaille@gmail.com
2021-08-03 Akim Demaille akim.demaille@gmail.com
2021-08-03 Akim Demaille akim.demaille@gmail.com
2021-08-03 Akim Demaille akim.demaille@gmail.com
2021-08-03 Akim Demaille akim.demaille@gmail.com
2021-08-01 Alyssa Ross hi@alyssa.is
2021-08-01 Akim Demaille akim.demaille@gmail.com
2021-07-25 Akim Demaille akim.demaille@gmail.com
2021-06-23 Akim Demaille akim.demaille@gmail.com
2021-06-06 Adela Vais adela.vais99@gmail.com
2021-04-11 Adela Vais adela.vais99@gmail.com
2021-04-11 Adela Vais adela.vais99@gmail.com
2021-04-11 Adela Vais adela.vais99@gmail.com
2021-03-26 Adela Vais adela.vais99@gmail.com
2021-03-26 Akim Demaille akim.demaille@gmail.com
2021-03-26 Adela Vais adela.vais99@gmail.com
2021-03-26 Akim Demaille akim.demaille@gmail.com
2021-03-10 Akim Demaille akim.demaille@gmail.com
2021-03-10 Akim Demaille akim.demaille@gmail.com
2021-03-08 Akim Demaille akim.demaille@gmail.com
2021-03-08 Akim Demaille akim.demaille@gmail.com