Skip to main content
  • Home
  • Development
  • Documentation
  • Donate
  • Operational login
  • Browse the archive

swh logo
SoftwareHeritage
Software
Heritage
Archive
Features
  • Search

  • Downloads

  • Save code now

  • Add forge now

  • Help

https://github.com/TakehideSoh/SAF
18 January 2026, 11:53:51 UTC
  • Code
  • Branches (4)
  • Releases (0)
  • Visits
    • Branches
    • Releases
    • HEAD
    • refs/heads/dev
    • refs/heads/main
    • refs/tags/v1.0-cmsb2023
    • refs/tags/v1.1-CMSB2023
    • d26cc9f94a4f79c046ee0cdd3a127a44f7b443b6
    No releases to show
  • 83aaea6
  • /
  • cadical
  • /
  • test
  • /
  • README.md
Raw File Download Save again
Take a new snapshot of a software origin

If the archived software origin currently browsed is not synchronized with its upstream version (for instance when new commits have been issued), you can explicitly request Software Heritage to take a new snapshot of it.

Use the form below to proceed. Once a request has been submitted and accepted, it will be processed as soon as possible. You can then check its processing state by visiting this dedicated page.
swh spinner

Processing "take a new snapshot" request ...

To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Hash IDentifiers (SWHIDs) must be used.
Select below a type of object currently browsed in order to display its associated SWHID and permalink.

  • content
  • directory
  • revision
  • snapshot
origin badgecontent badge
swh:1:cnt:0d488c0b930b1111d9b1948d5a5d7711183dac16
origin badgedirectory badge
swh:1:dir:357de81e29046228a4a4c76240f09e94b40d51f5
origin badgerevision badge
swh:1:rev:d26cc9f94a4f79c046ee0cdd3a127a44f7b443b6
origin badgesnapshot badge
swh:1:snp:d3fcf0e446f52630e867f11dee4c2c828bf46951

This interface enables to generate software citations, provided that the root directory of browsed objects contains a citation.cff or codemeta.json file.
Select below a type of object currently browsed in order to generate citations for them.

  • content
  • directory
  • revision
  • snapshot
Generate software citation in BibTex format (requires biblatex-software package)
Generating citation ...
Generate software citation in BibTex format (requires biblatex-software package)
Generating citation ...
Generate software citation in BibTex format (requires biblatex-software package)
Generating citation ...
Generate software citation in BibTex format (requires biblatex-software package)
Generating citation ...
Tip revision: d26cc9f94a4f79c046ee0cdd3a127a44f7b443b6 authored by TakehideSoh on 23 June 2023, 07:02:26 UTC
Merge pull request #2 from TakehideSoh/dev
Tip revision: d26cc9f
README.md
The tests can be executed by `make test` from a configured build,  the `src`
or `test` directory and will put their intermediate and log files in the
build directory.  If called from outside from the build directory the last
configured build directory is used.

We have four test drivers.  The simplest one

    ./api/run.sh

is going through the API directly to test basic stand-alone functionality of
the library.  Next is a simple usage test for all command line options.

    ./usage/run.sh

The regression suite for CNF files

    ./cnf/run.sh

is more thorough and should catch simple bugs.  It checks solutions and
checks generated proofs too.  The third test driver uses a regression suite
and executes traces by replaying them through `mobical`

    ./traces/run.sh

Last but not least the model based tester `../src/mobical.cpp` is the
most effective test driver and can be run through

    ./mbt/run.sh

All test drivers place their intermediate and logging files into the build
directory.  Thus if for instance you build in a `release` subdirectory
within the root directory of CaDiCaL

    mkdir release
    cd release
    ../configure
    make test

will use the library and binaries in this `release` sub-directory for
running all the tests.  The log files including generated proofs are all put
into the `release` subdirectory too.

For more information on external fuzz-testing see

> Robert Brummayer, Florian Lonsing, Armin Biere:
> Automated Testing and Debugging of SAT and QBF Solvers. SAT 2010: 44-57

Model based testing of SAT solvers is described in

> Cyrille Artho, Armin Biere, Martina Seidl:
> Model-Based Testing for Verification Back-Ends. TAP 2013: 39-55

The simple API test driver and the regression suite are executed by the
default goal of the `makefile`.  There is no need to clean up test output
since it is all put into the build directory.

back to top

Software Heritage — Copyright (C) 2015–2026, The Software Heritage developers. License: GNU AGPLv3+.
The source code of Software Heritage itself is available on our development forge.
The source code files archived by Software Heritage are available under their own copyright and licenses.
Terms of use: Archive access, API— Content policy— Contact— JavaScript license information— Web API