Some autotools-based projects (notably, XTerm) don't define any check (nor test) target.

Still, check target execution is attempted by the runner even if the corresponding field value is empty (this is the intended behaviour):

The issue can be worked around by specifying the same target (e.g.: all) for both the build and the test phases.

Решения всех алгоритмических задач (т. е. всех, кроме последней) должны быть выполнены на любом из языков, поддерживаемых JVM (Java, Scala, Kotlin, Groovy, Clojure и т. д.) без использования сторонних библиотек (кроме runtime-библиотеки выбранного Вами языка) и собираться любым из стандартных инструментов (Gradle, Maven, SBT, Leiningen), т. е. в корневом каталоге каждого решения должен присутствовать соотв. файл для сборки (pom.xml, build.gradle).

Также должен быть предусмотрен простой запуск решения (напр., в случае Maven, посредством mvn exec:java).

В качестве альтернативы, решение может быть выполнено на C или C++ с использованием одной лишь стандартной библиотеки, при этом обязательно наличие Makefile'а или интеграция с любой стандартной системой сборки (CMake, Autotools, SCons). Решение должно собираться GCC и/или LLVM.

Решение каждой из алгоритмических задач должно печатать (на стандартный вывод) только численный ответ, т. е. вывод должен выглядеть как, напр.,

3.1415926

а не

Pi=3.1415926

Код каждого из решений может быть оформлен как закрытый Git-репозиторий на bitbucket.org с правами на чтение для пользователя bass.

Алгоритмические задачи

1. Сумма последовательности

   1¹ + 2² + 3³ + ... + 10¹⁰

   равна 10405071317. Найдите последние 10 цифр суммы последовательности

   1¹ + 2² + 3³ + ... + 1000¹⁰⁰⁰

2. Ряд Фибоначчи задаётся рекуррентным соотношением:

   F_n = F_n−1 + F_n−2, где F₁ = 1 и F₂ = 1.

   Следовательно, первыми 12-ю членами ряда будут:

   F₁ = 1
   F₂ = 1
   F₃ = 2
   F₄ = 3
   F₅ = 5
   F₆ = 8
   F₇ = 13
   F₈ = 21
   F₉ = 34
   F₁₀ = 55
   F₁₁ = 89
   F₁₂ = 144

   12-й член ряда, F₁₂, — это первый член, в десятичной записи которого три цифры.

   Каков индекс первого члена ряда Фибоначчи, в десятичной записи которого 1000 цифр?

3. Факториал 10 равен

   10! = 10 × 9 × ... × 3 × 2 × 1 = 3628800,

   а сумма цифр десятичной записи числа равна

   3 + 6 + 2 + 8 + 8 + 0 + 0 = 27.

   Найдите сумму цифр десятичной записи числа 100!

4. 2¹⁵ = 32768, а сумма цифр числа равна

   3 + 2 + 7 + 6 + 8 = 26.

   Какова сумма цифр десятичной записи числа 2¹⁰⁰⁰?

5. Последовательность натуральных чисел задаётся следующими правилами:

   n → n/2, если n чётно;
   n → 3n + 1, если n нечётно.

   Используя их и выбирая 13 в качестве первого члена, получаем последовательность:

   13 → 40 → 20 → 10 → 5 → 16 → 8 → 4 → 2 → 1

   Видно, что эта последовательность конечна и содержит ровно 10 членов. Хотя это до сих пор и не доказано (см. гипотеза Коллатца), предполагается, что, вне зависимости от выбора первого члена, все подобные последовательности конечны и последним своим членом имеют единицу.

   Если потребовать, чтобы первый член последовательности был строго меньше 1000000, то при каком выборе первого члена последовательность будет иметь наибольшую длину?

   Примечание: ограничение распространяется только на первый член; значения последующих членов могут превышать один миллион.

Задачи на владение инструментами

1. Создайте простейший проект на C или C++ (GCC, Autotools) с реализацией native-метода Java посредством JNI (в виде разделяемой библиотеки — *.so).

   Требования:

   • Сценарий configure должен находить (если java в переменной PATH или определена переменная JAVA_HOME) хедер jni.h и библиотеку libjvm.so, создавая Makefile с корректными CFLAGS и LDFLAGS.
   • Сценарий configure должен принимать аргумент --with-java-home=..., позволяющий указать каталог установки JDK явно.
   • Если установка JDK не обнаружена, сценарий configure должен выводить понятное сообщение об ошибке.
   • Реализация native-метода Java должна просто бросать (произвольное, на Ваш выбор) Java-исключение с непустым сообщением.
   • Хедер-файл, соответствующий Java-классу (com_example_SomeClass.h) должен автоматически создаваться из Java-класса (утилитой javah). Сгенерированный Makefile должен содержать необходимые инструкции.

E.g.:

  <test>
    <input></input>
    <output></output>
    <result>PASS</result>
    <name>i386 float AT&T mnemonic</name>
    <prms_id>0</prms_id>
  </test>

Both options control whether workarounds for buggy DejaGnu versions (1.5.x, 1.6.0) will be applied. Since these workarounds are safe (neither of them can corrupt a well-formed XML), we should have them enabled permanently and remove the corresponding check boxes from the UI.

Currently, parameter description for an already configured build step is empty:

It should list the following:

• the configure arguments;
• the build-phase make targets;
• the test-phase make targets (if any).

Related: #13

Speed up search for DejaGnu XML reports in case there're multiple non-DejaGnu XML files in the build directory (e. g. for glib).

Makefile's, config.log and/or config.h which are published in case the configure or the build phase fails, should be published as internal artifacts (under .autotools/, similarly to .teamcity/).

Currently, the auto-detected GNU Autotools build step provides no parameter description:

Instead, the description should read like this:

• configure.ac under /
• configure and configure.ac under /
• configure.ac under / and libxyz/
• configure.ac under / and configure.in under libxyz/

Related: #17

The "Extra configure parameters" field is always highlighted as holding a non-default value, even if the parameters are blank (an empty string, ""):

Currently, the build runner can tell which particular phase (the configure, the build or the test) has failed and raise a separate build problem.

It would make sense, however, to implement a smarter behaviour and detect the standard autoconf, gcc and clang error messages and warnings, most probably using the Process Output Parsers plug-in.

We could watch when DejaGnu XML test reports and *.trs files get closed and publish test results (via service messages) to be processed by the stock XML Report Plug-in immediately, before the build finishes.

Test TeamCity TAP Plug-in against any of the Autotools projects which use TAP for test reporting.

Later, we may (or may not) want to rely on the tap4j library (available under the MIT license) rather than maintain our custom TAP support.

See also https://instanttap.appspot.com/.

DejaGnu (at least, 1.6) can generate malformed XML reports when test output contains ASCII control codes.

Example:

  <test>
    <input></input>
    <output>��query</output>
    <result>PASS</result>
    <name>gdb.base/annota-input-while-running.exp: delete breakpoints</name>
    <prms_id>0</prms_id>
  </test>
  <test>
    <input></input>
    <output>��query</output>
    <result>PASS</result>
    <name>gdb.base/annota-input-while-running.exp: break after sleep</name>
    <prms_id>0</prms_id>
  </test>

^Z (or 0x1A) should be escaped as &#x001A. Other control codes should be escaped similarly.

See also https://stackoverflow.com/questions/404107.

GNU Autotools build runner settings are empty (and differ from the default values) if build step is added via autodetection:

This is not the case if build step is added manually.

When make is invoked with -j, multiple make instances will run simultaneously. To make sure their output is not interspersed, we'll also need to add -O=... to the MAKEFLAGS variable:

       -O[type], --output-sync[=type]
            When running multiple jobs in parallel with -j, ensure the  output
            of  each  job  is collected together rather than interspersed with
            output from other jobs.  If type is not specified or is target the
            output from the entire recipe for each target is grouped together.
            If type is line the output from each command line within a  recipe
            is  grouped  together.   If  type is recurse output from an entire
            recursive make is grouped together.  If type is none  output  syn-
            chronization is disabled.

Earlier runtest versions (e.g.: 1.4.4) don't accept any --xml option, and will fail if one is present in the RUNTESTFLAGS variable.

If we can't parse the log files, we need at least the correct RUNTESTFLAGS so that the tool doesn't fail (or, additionally, we can collect testrun.log and testrun.sum file pairs and publish them as artifacts).

Version output:

$ runtest --version
Expect version is       5.45
Tcl version is          8.5
Framework version is    1.4.4

Manual page:

$ man runtest
runtest(1)                  General Commands Manual                 runtest(1)

NAME
       runtest - the DejaGnu test driver program

SYNOPSIS
       runtest [ options ]

DESCRIPTION
       DejaGnu  is  a  framework  for  running test suites on GNU tools. It is
       written in expect, which uses Tcl (Tool command language).  runtest  is
       the test driver program; use it to control what tests to run, and vari‐
       ations on how to run them.

       You can find a comprehensive description of DejaGnu and runtest in  The
       DejaGnu Testing Framework or its Info version, dejagnu.info.

OPTIONS
       --all  Print  all  test  output  to screen. By default, only unexpected
              results are displayed.

       --baud rate
              Set the baud rate for a  serial  line  connection.  Some  serial
              interface  programs  (like tip) don't use this value but instead
              use a separate initialization file.

       --connect type
              The type of connection to use.  The choices are rlogin,  telnet,
              rsh, kermit, tip and mondfe.

       --debug
              Turn  on  expect internal debugging output. All output is logged
              to a file called dbg.out.  The output of the --strace also  goes
              into this file.

       --help Prints out a help screen and then exits.

       --host type
              The configuration string for the host.

       --ignore test1.exp test2.exp ...
              Do not run the specified tests.

       --mail ´name1 name2 ...´
              Electronic mail addresses to receive test results.

       --name hostname
              The network hostname of the target board.

       --objdir path
              path is a directory containing compiled test code.

       --outdir directory
              The name of a directory for test log output.

       --reboot
              Reboot the target board when runtest initializes (if supported).

       --srcdir path
              path is a directory containing test directories.

       --strace N
              Turns on expect internal tracing to N levels deep.

       --target type
              The configuration string for the target.

       --tool toolname
              Specify the tool to be tested.  toolname controls the test suite
              applied, and the associated initialization module.

       --verbose, -v
              Turns on more debugging output from test cases and DejaGnu util‐
              ity code.  Use more than once to increase output further.

       --version, -V
              Prints out the versions of DejaGnu, expect and Tcl.

       -D[number]
              Activate  the Tcl debugger.number can be either 1 or 0. If it is
              1, then the expect shell will break when it starts to  run.  All
              ^C's  drop  DejaGnu  back  to  the  debugger  prompt. A 0 starts
              DejaGnu like normal, but a ^C drops to the debugger prompt.

       Any file name on the command line is assumed to be a subset
       of the test names to run.  Usually these are the names  of  the  expect
       test driver, ie... special.exp.

       Makefile  style  variables  are  used  to  specify tool names and their
       flags; these and other configuration dependent values are saved in  the
       file site.exp, created during configuration.

EXIT CODES
       runtest  sets the exit code to 1 if any of the tests failed, or sets it
       to 0 if all the tests passed.

SEE ALSO
       The DejaGnu Testing Framework (dejagnu.info).  This is the DejaGnu man‐
       ual; its source is the SGML files doc/*.sgml.  in the DejaGnu distribu‐
       tion.

AUTHOR
       Rob Savoye ([email protected])

                                  29 Jul 2003                       runtest(1)

1.4.4 (doesn't accept any --xml flag):

Expect version is       5.45
Tcl version is          8.5
Framework version is    1.4.4

1.5.1 (accepts the --xml flag w/o any argument):

Expect version is       5.45
Tcl version is          8.6
Framework version is    1.5.1

1.5.3 (the --xml flag requires an argument):

Expect version is       5.45
Tcl version is          8.6
Framework version is    1.5.3

1.6 (the --xml flag requires an argument):

DejaGnu version 1.6
Expect version  5.45
Tcl version     8.6