début du cours d'algorithmique pour le CESI
This commit is contained in:
gwen
parent
d7a4bcc466
commit
9cbe2e337a
|
|
@ -0,0 +1,216 @@
|
|||
# Makefile for Sphinx documentation
|
||||
#
|
||||
|
||||
# You can set these variables from the command line.
|
||||
SPHINXOPTS =
|
||||
SPHINXBUILD = sphinx-build
|
||||
PAPER =
|
||||
BUILDDIR = _build
|
||||
|
||||
# User-friendly check for sphinx-build
|
||||
ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
|
||||
$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
|
||||
endif
|
||||
|
||||
# Internal variables.
|
||||
PAPEROPT_a4 = -D latex_paper_size=a4
|
||||
PAPEROPT_letter = -D latex_paper_size=letter
|
||||
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
|
||||
# the i18n builder cannot share the environment and doctrees with the others
|
||||
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
|
||||
|
||||
.PHONY: help
|
||||
help:
|
||||
@echo "Please use \`make <target>' where <target> is one of"
|
||||
@echo " html to make standalone HTML files"
|
||||
@echo " dirhtml to make HTML files named index.html in directories"
|
||||
@echo " singlehtml to make a single large HTML file"
|
||||
@echo " pickle to make pickle files"
|
||||
@echo " json to make JSON files"
|
||||
@echo " htmlhelp to make HTML files and a HTML help project"
|
||||
@echo " qthelp to make HTML files and a qthelp project"
|
||||
@echo " applehelp to make an Apple Help Book"
|
||||
@echo " devhelp to make HTML files and a Devhelp project"
|
||||
@echo " epub to make an epub"
|
||||
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
|
||||
@echo " latexpdf to make LaTeX files and run them through pdflatex"
|
||||
@echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
|
||||
@echo " text to make text files"
|
||||
@echo " man to make manual pages"
|
||||
@echo " texinfo to make Texinfo files"
|
||||
@echo " info to make Texinfo files and run them through makeinfo"
|
||||
@echo " gettext to make PO message catalogs"
|
||||
@echo " changes to make an overview of all changed/added/deprecated items"
|
||||
@echo " xml to make Docutils-native XML files"
|
||||
@echo " pseudoxml to make pseudoxml-XML files for display purposes"
|
||||
@echo " linkcheck to check all external links for integrity"
|
||||
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
|
||||
@echo " coverage to run coverage check of the documentation (if enabled)"
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -rf $(BUILDDIR)/*
|
||||
|
||||
.PHONY: html
|
||||
html:
|
||||
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
|
||||
@echo
|
||||
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
|
||||
|
||||
.PHONY: dirhtml
|
||||
dirhtml:
|
||||
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
|
||||
@echo
|
||||
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
|
||||
|
||||
.PHONY: singlehtml
|
||||
singlehtml:
|
||||
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
|
||||
@echo
|
||||
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
|
||||
|
||||
.PHONY: pickle
|
||||
pickle:
|
||||
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
|
||||
@echo
|
||||
@echo "Build finished; now you can process the pickle files."
|
||||
|
||||
.PHONY: json
|
||||
json:
|
||||
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
|
||||
@echo
|
||||
@echo "Build finished; now you can process the JSON files."
|
||||
|
||||
.PHONY: htmlhelp
|
||||
htmlhelp:
|
||||
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
|
||||
@echo
|
||||
@echo "Build finished; now you can run HTML Help Workshop with the" \
|
||||
".hhp project file in $(BUILDDIR)/htmlhelp."
|
||||
|
||||
.PHONY: qthelp
|
||||
qthelp:
|
||||
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
|
||||
@echo
|
||||
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
|
||||
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
|
||||
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Algorithmique.qhcp"
|
||||
@echo "To view the help file:"
|
||||
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Algorithmique.qhc"
|
||||
|
||||
.PHONY: applehelp
|
||||
applehelp:
|
||||
$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
|
||||
@echo
|
||||
@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
|
||||
@echo "N.B. You won't be able to view it unless you put it in" \
|
||||
"~/Library/Documentation/Help or install it in your application" \
|
||||
"bundle."
|
||||
|
||||
.PHONY: devhelp
|
||||
devhelp:
|
||||
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
|
||||
@echo
|
||||
@echo "Build finished."
|
||||
@echo "To view the help file:"
|
||||
@echo "# mkdir -p $$HOME/.local/share/devhelp/Algorithmique"
|
||||
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Algorithmique"
|
||||
@echo "# devhelp"
|
||||
|
||||
.PHONY: epub
|
||||
epub:
|
||||
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
|
||||
@echo
|
||||
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
|
||||
|
||||
.PHONY: latex
|
||||
latex:
|
||||
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||
@echo
|
||||
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
|
||||
@echo "Run \`make' in that directory to run these through (pdf)latex" \
|
||||
"(use \`make latexpdf' here to do that automatically)."
|
||||
|
||||
.PHONY: latexpdf
|
||||
latexpdf:
|
||||
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||
@echo "Running LaTeX files through pdflatex..."
|
||||
$(MAKE) -C $(BUILDDIR)/latex all-pdf
|
||||
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
|
||||
|
||||
.PHONY: latexpdfja
|
||||
latexpdfja:
|
||||
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||
@echo "Running LaTeX files through platex and dvipdfmx..."
|
||||
$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
|
||||
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
|
||||
|
||||
.PHONY: text
|
||||
text:
|
||||
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
|
||||
@echo
|
||||
@echo "Build finished. The text files are in $(BUILDDIR)/text."
|
||||
|
||||
.PHONY: man
|
||||
man:
|
||||
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
|
||||
@echo
|
||||
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
|
||||
|
||||
.PHONY: texinfo
|
||||
texinfo:
|
||||
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
|
||||
@echo
|
||||
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
|
||||
@echo "Run \`make' in that directory to run these through makeinfo" \
|
||||
"(use \`make info' here to do that automatically)."
|
||||
|
||||
.PHONY: info
|
||||
info:
|
||||
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
|
||||
@echo "Running Texinfo files through makeinfo..."
|
||||
make -C $(BUILDDIR)/texinfo info
|
||||
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
|
||||
|
||||
.PHONY: gettext
|
||||
gettext:
|
||||
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
|
||||
@echo
|
||||
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
|
||||
|
||||
.PHONY: changes
|
||||
changes:
|
||||
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
|
||||
@echo
|
||||
@echo "The overview file is in $(BUILDDIR)/changes."
|
||||
|
||||
.PHONY: linkcheck
|
||||
linkcheck:
|
||||
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
|
||||
@echo
|
||||
@echo "Link check complete; look for any errors in the above output " \
|
||||
"or in $(BUILDDIR)/linkcheck/output.txt."
|
||||
|
||||
.PHONY: doctest
|
||||
doctest:
|
||||
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
|
||||
@echo "Testing of doctests in the sources finished, look at the " \
|
||||
"results in $(BUILDDIR)/doctest/output.txt."
|
||||
|
||||
.PHONY: coverage
|
||||
coverage:
|
||||
$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
|
||||
@echo "Testing of coverage in the sources finished, look at the " \
|
||||
"results in $(BUILDDIR)/coverage/python.txt."
|
||||
|
||||
.PHONY: xml
|
||||
xml:
|
||||
$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
|
||||
@echo
|
||||
@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
|
||||
|
||||
.PHONY: pseudoxml
|
||||
pseudoxml:
|
||||
$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
|
||||
@echo
|
||||
@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
|
|
@ -0,0 +1,355 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# Algorithmique documentation build configuration file, created by
|
||||
# sphinx-quickstart on Thu Mar 16 16:07:00 2017.
|
||||
#
|
||||
# This file is execfile()d with the current directory set to its
|
||||
# containing dir.
|
||||
#
|
||||
# Note that not all possible configuration values are present in this
|
||||
# autogenerated file.
|
||||
#
|
||||
# All configuration values have a default; values that are commented out
|
||||
# serve to show the default.
|
||||
|
||||
import sys
|
||||
import os
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#sys.path.insert(0, os.path.abspath('.'))
|
||||
|
||||
# -- General configuration ------------------------------------------------
|
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here.
|
||||
#needs_sphinx = '1.0'
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = [
|
||||
'sphinx.ext.pngmath',
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
# The suffix(es) of source filenames.
|
||||
# You can specify multiple suffix as a list of string:
|
||||
# source_suffix = ['.rst', '.md']
|
||||
source_suffix = '.txt'
|
||||
|
||||
# The encoding of source files.
|
||||
#source_encoding = 'utf-8-sig'
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = u'Algorithmique'
|
||||
copyright = u'2017, Gwen'
|
||||
author = u'Gwen'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
# built documents.
|
||||
#
|
||||
# The short X.Y version.
|
||||
version = u'1'
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = u'1'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
#
|
||||
# This is also used if you do content translation via gettext catalogs.
|
||||
# Usually you set "language" from the command line for these cases.
|
||||
language = 'fr'
|
||||
|
||||
# There are two options for replacing |today|: either, you set today to some
|
||||
# non-false value, then it is used:
|
||||
#today = ''
|
||||
# Else, today_fmt is used as the format for a strftime call.
|
||||
#today_fmt = '%B %d, %Y'
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
exclude_patterns = ['_build']
|
||||
|
||||
# The reST default role (used for this markup: `text`) to use for all
|
||||
# documents.
|
||||
default_role = 'literal'
|
||||
|
||||
# If true, '()' will be appended to :func: etc. cross-reference text.
|
||||
#add_function_parentheses = True
|
||||
|
||||
# If true, the current module name will be prepended to all description
|
||||
# unit titles (such as .. function::).
|
||||
#add_module_names = True
|
||||
|
||||
# If true, sectionauthor and moduleauthor directives will be shown in the
|
||||
# output. They are ignored by default.
|
||||
#show_authors = False
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
|
||||
# A list of ignored prefixes for module index sorting.
|
||||
#modindex_common_prefix = []
|
||||
|
||||
# If true, keep warnings as "system message" paragraphs in the built documents.
|
||||
#keep_warnings = False
|
||||
|
||||
# If true, `todo` and `todoList` produce output, else they produce nothing.
|
||||
todo_include_todos = False
|
||||
|
||||
|
||||
# -- Options for HTML output ----------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
html_theme = 'alabaster'
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
#html_theme_options = {}
|
||||
|
||||
# Add any paths that contain custom themes here, relative to this directory.
|
||||
#html_theme_path = []
|
||||
|
||||
# The name for this set of Sphinx documents. If None, it defaults to
|
||||
# "<project> v<release> documentation".
|
||||
#html_title = None
|
||||
|
||||
# A shorter title for the navigation bar. Default is the same as html_title.
|
||||
#html_short_title = None
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top
|
||||
# of the sidebar.
|
||||
#html_logo = None
|
||||
|
||||
# The name of an image file (relative to this directory) to use as a favicon of
|
||||
# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
|
||||
# pixels large.
|
||||
#html_favicon = None
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
# Add any extra paths that contain custom files (such as robots.txt or
|
||||
# .htaccess) here, relative to this directory. These files are copied
|
||||
# directly to the root of the documentation.
|
||||
#html_extra_path = []
|
||||
|
||||
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
|
||||
# using the given strftime format.
|
||||
#html_last_updated_fmt = '%b %d, %Y'
|
||||
|
||||
# If true, SmartyPants will be used to convert quotes and dashes to
|
||||
# typographically correct entities.
|
||||
#html_use_smartypants = True
|
||||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
#html_sidebars = {}
|
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to
|
||||
# template names.
|
||||
#html_additional_pages = {}
|
||||
|
||||
# If false, no module index is generated.
|
||||
#html_domain_indices = True
|
||||
|
||||
# If false, no index is generated.
|
||||
#html_use_index = True
|
||||
|
||||
# If true, the index is split into individual pages for each letter.
|
||||
#html_split_index = False
|
||||
|
||||
# If true, links to the reST sources are added to the pages.
|
||||
#html_show_sourcelink = True
|
||||
|
||||
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
|
||||
html_show_sphinx = False
|
||||
|
||||
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
|
||||
html_show_copyright = False
|
||||
|
||||
# If true, an OpenSearch description file will be output, and all pages will
|
||||
# contain a <link> tag referring to it. The value of this option must be the
|
||||
# base URL from which the finished HTML is served.
|
||||
#html_use_opensearch = ''
|
||||
|
||||
# This is the file name suffix for HTML files (e.g. ".xhtml").
|
||||
#html_file_suffix = None
|
||||
|
||||
# Language to be used for generating the HTML full-text search index.
|
||||
# Sphinx supports the following languages:
|
||||
# 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
|
||||
# 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
|
||||
#html_search_language = 'en'
|
||||
|
||||
# A dictionary with options for the search language support, empty by default.
|
||||
# Now only 'ja' uses this config value
|
||||
#html_search_options = {'type': 'default'}
|
||||
|
||||
# The name of a javascript file (relative to the configuration directory) that
|
||||
# implements a search results scorer. If empty, the default will be used.
|
||||
#html_search_scorer = 'scorer.js'
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'Algorithmiquedoc'
|
||||
|
||||
# -- Options for LaTeX output ---------------------------------------------
|
||||
|
||||
latex_elements = {
|
||||
# The paper size ('letterpaper' or 'a4paper').
|
||||
'papersize': 'a4paper',
|
||||
|
||||
# The font size ('10pt', '11pt' or '12pt').
|
||||
#'pointsize': '10pt',
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#'preamble': '',
|
||||
|
||||
# Latex figure (float) alignment
|
||||
#'figure_align': 'htbp',
|
||||
}
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title,
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
(master_doc, 'Algorithmique.tex', u'Cours d\'algorithmique',
|
||||
u'promotion GMSI B3', 'manual'),
|
||||
]
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
# the title page.
|
||||
latex_logo = '_static/cesi.jpg'
|
||||
|
||||
# For "manual" documents, if this is true, then toplevel headings are parts,
|
||||
# not chapters.
|
||||
latex_use_parts = True
|
||||
|
||||
# If true, show page references after internal links.
|
||||
#latex_show_pagerefs = False
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
#latex_show_urls = False
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#latex_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
#latex_domain_indices = False
|
||||
|
||||
|
||||
# -- Options for manual page output ---------------------------------------
|
||||
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
(master_doc, 'algorithmique', u'Algorithmique Documentation',
|
||||
[author], 1)
|
||||
]
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
#man_show_urls = False
|
||||
|
||||
|
||||
# -- Options for Texinfo output -------------------------------------------
|
||||
|
||||
# Grouping the document tree into Texinfo files. List of tuples
|
||||
# (source start file, target name, title, author,
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
(master_doc, 'Algorithmique', u'Algorithmique Documentation',
|
||||
author, 'Algorithmique', 'One line description of project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#texinfo_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
#texinfo_domain_indices = True
|
||||
|
||||
# How to display URL addresses: 'footnote', 'no', or 'inline'.
|
||||
#texinfo_show_urls = 'footnote'
|
||||
|
||||
# If true, do not generate a @detailmenu in the "Top" node's menu.
|
||||
#texinfo_no_detailmenu = False
|
||||
|
||||
|
||||
# -- Options for Epub output ----------------------------------------------
|
||||
|
||||
# Bibliographic Dublin Core info.
|
||||
epub_title = project
|
||||
epub_author = author
|
||||
epub_publisher = author
|
||||
epub_copyright = copyright
|
||||
|
||||
# The basename for the epub file. It defaults to the project name.
|
||||
#epub_basename = project
|
||||
|
||||
# The HTML theme for the epub output. Since the default themes are not
|
||||
# optimized for small screen space, using the same theme for HTML and epub
|
||||
# output is usually not wise. This defaults to 'epub', a theme designed to save
|
||||
# visual space.
|
||||
#epub_theme = 'epub'
|
||||
|
||||
# The language of the text. It defaults to the language option
|
||||
# or 'en' if the language is not set.
|
||||
#epub_language = ''
|
||||
|
||||
# The scheme of the identifier. Typical schemes are ISBN or URL.
|
||||
#epub_scheme = ''
|
||||
|
||||
# The unique identifier of the text. This can be a ISBN number
|
||||
# or the project homepage.
|
||||
#epub_identifier = ''
|
||||
|
||||
# A unique identification for the text.
|
||||
#epub_uid = ''
|
||||
|
||||
# A tuple containing the cover image and cover page html template filenames.
|
||||
#epub_cover = ()
|
||||
|
||||
# A sequence of (type, uri, title) tuples for the guide element of content.opf.
|
||||
#epub_guide = ()
|
||||
|
||||
# HTML files that should be inserted before the pages created by sphinx.
|
||||
# The format is a list of tuples containing the path and title.
|
||||
#epub_pre_files = []
|
||||
|
||||
# HTML files that should be inserted after the pages created by sphinx.
|
||||
# The format is a list of tuples containing the path and title.
|
||||
#epub_post_files = []
|
||||
|
||||
# A list of files that should not be packed into the epub file.
|
||||
epub_exclude_files = ['search.html']
|
||||
|
||||
# The depth of the table of contents in toc.ncx.
|
||||
#epub_tocdepth = 3
|
||||
|
||||
# Allow duplicate toc entries.
|
||||
#epub_tocdup = True
|
||||
|
||||
# Choose between 'default' and 'includehidden'.
|
||||
#epub_tocscope = 'default'
|
||||
|
||||
# Fix unsupported image types using the Pillow.
|
||||
#epub_fix_images = False
|
||||
|
||||
# Scale large images.
|
||||
#epub_max_image_width = 0
|
||||
|
||||
# How to display URL addresses: 'footnote', 'no', or 'inline'.
|
||||
#epub_show_urls = 'inline'
|
||||
|
||||
# If false, no index is generated.
|
||||
#epub_use_index = True
|
||||
|
|
@ -0,0 +1,99 @@
|
|||
Présentation de l'art de programmer
|
||||
====================================
|
||||
|
||||
Le processus d'abstraction
|
||||
--------------------------
|
||||
|
||||
Débuter en programmation n'est pas une chose aisée. Aujourd'hui, la tendance est au
|
||||
"bas niveau". Souvent, on se jette dans le grand bain :
|
||||
|
||||
- soit en s'approchant au maximum de la machine (admin système et réseau, noyau
|
||||
linux, langage C)
|
||||
|
||||
- soit en faisant du dev web côté backend, ce qui ramène à une administration réseau
|
||||
de bas niveau (microservices, monde nodeJS/javascript, etc...)
|
||||
|
||||
Soit on suit un cursus scolaire traditionnel qui commence souvent par une
|
||||
explication du fonctionnement d'une machine abstraite de bas niveau, puis en
|
||||
allant de plus en plus haut, mais étant sous-entendu qu'il faut rester connecté au
|
||||
bas niveau (comprendre comment ça se passe derrière la scène).
|
||||
|
||||
Dans ces deux cas, il est sous-entendu qu'on apprend plus de choses et plus
|
||||
rapidement en mettant les mains dans le cambouis, ce qui vrai bien sûr. Mais cela
|
||||
sous-entend qu'un développeur doit rester le nez dans le guidon, ou au moins qu'il
|
||||
se doit d'être un expert du système dans lequel il évolue (connaissance du système
|
||||
d'exploitation, binding avec le C, du ramasse miette (garbage collector),
|
||||
interaction avec les différentes librairies, gestion et optimisation de la mémoire,
|
||||
architecture par microservices, threads...)
|
||||
|
||||
L'approche algorithmique consiste en exactement le contraire : elle commence par se
|
||||
placer du côté de l'esprit humain et de ses capacités de compréhension et
|
||||
d'abstraction.
|
||||
|
||||
Le lien est fait ensuite avec le plus bas niveau grâce une implémentation effective
|
||||
des langages à partir des paradigmes de rationalisation de la penseée (modules,
|
||||
objects, généricité, polymorphisme paramétrique...) et d'un outil de communication
|
||||
avec la machine qu'on appelle compilateur (dont la description est en dehors de
|
||||
l'objectif de ce cours).
|
||||
|
||||
La tendance générale de l'évolution des languages est de se libérer de ces
|
||||
contraintes de bas niveau, un peu comme en sciences physiques où les lois physiques
|
||||
dépendent de l'échelle d'en dessous (du niveau microscopique/quantique) mais qu'à
|
||||
l'échelle du dessus, on n'a pas affaire à des effets de bas niveau (pas d'effets
|
||||
quantiques à un niveau macroscopique en général). Ce processus d'évolution est vrai
|
||||
aussi dans le monde de la technique informatique lui-même (modèle OSI, comment est
|
||||
construite une trame IP, indépendances de chaque couche (transport, payload) entre
|
||||
elles). Même la tendance système est à la virtualisation qui accentue encore la
|
||||
tendance à s'affranchir du bas niveau (le niveau système), le séparer nettement du
|
||||
haut niveau (le niveau applicatif).
|
||||
|
||||
Il apparaît régulièrement de nouveaux langages. Comment s'orienter ? Quel(s)
|
||||
langage(s) choisir pour un projet de développement ? Au delà de leurs disparités, la
|
||||
conception et la genèse de chacun d'eux procèdent d'une motivation partagée : la
|
||||
volonté d'abstraire.
|
||||
|
||||
- **s'abstraire de la machine** : un langage de programmation permet de
|
||||
négliger l'aspect *mécanique* de l'ordinateur. On oublie le modèle du
|
||||
microprocesseur, jusqu'au système d'exploitation sur lequel sera exécuté
|
||||
le programme.
|
||||
|
||||
- **abstraire les erreurs** : Il s'agit ici de garantir la sûreté d'exécution; un
|
||||
programme ne doit pas se terminer brutalement ou devenir incohérent en cas d'erreur.
|
||||
Un des moyens pour y parvenir est le typage des programmes et la mise
|
||||
en oeuvre d'un mécanisme d'exceptions.
|
||||
|
||||
- **abstraire le mode opératoire** : Il s'agit de choisir une représentation, un
|
||||
paradigme d'implémentation qui est indépendant du domaine considéré (paradigme
|
||||
objet, modulaire, générique, composants...)
|
||||
|
||||
- **abstraire les composants** : Les langages de programmation donnent la
|
||||
possibilité de découper une application en différents composants logiciels, plus ou
|
||||
moins indépendants et autonomes. La modularité permet une structuration de plus haut
|
||||
niveau de l'ensemble d'une application complexe. Les langages à objets constituent
|
||||
une autre approche de la réutilisabilité permettant la réalisation très rapide de
|
||||
prototypes.
|
||||
|
||||
Détails des niveaux d'abstraction par rapport à la machine
|
||||
-----------------------------------------------------------
|
||||
|
||||
L'extrème déploiement des langages (plusieurs milliers de langages différents)
|
||||
est dû au succès de l'ordinateur.
|
||||
|
||||
- **niveau 0** : le langage machine. Illisible, c'est une suite d'optcode.
|
||||
impossible de coder dans ce langage.
|
||||
|
||||
- **niveau 1** : langage d'assemblage. Il reste très dépendant de la machine
|
||||
et aujourd'hui il est rare d'en faire, sauf si on code un bootloader par exemple,
|
||||
la gestion de l'accès à la mémoire est en réel (le mode protégé n'apparaît que après).
|
||||
Il faut gérer les ressources,le langage est très optimisé mais presque impossible
|
||||
à maintenir et rendre générique. Aujourd'hui plus personne ne code en assembleur.
|
||||
|
||||
- **niveau 2** : langages dits de **bas niveau** : (exemple : le C, le C++)
|
||||
indépendance par rapport à la machine, grande structuration mais très verbeux
|
||||
|
||||
- **niveau 3** : langages dits de **haut niveau** : le raisonnement dans ces
|
||||
langages ne dépent plus de la machine, et ils implémentent des paradigmes de
|
||||
programmation indépendant de l'état de la mémoire de l'ordinateur,
|
||||
ils sont indépendant même du système d'exploitation.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
.. Algorithmique documentation master file, created by
|
||||
sphinx-quickstart on Thu Mar 16 16:07:00 2017.
|
||||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
Introduction à l'algorithmique
|
||||
================================
|
||||
|
||||
Contents:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
fondement
|
||||
langage
|
||||
modularite
|
||||
|
||||
|
||||
.. algorithmique
|
||||
|
||||
|
||||
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
||||
* :ref:`search`
|
||||
|
||||
|
|
@ -0,0 +1,220 @@
|
|||
Les langages de programmation
|
||||
=============================
|
||||
|
||||
Approche historique et chronologique
|
||||
-------------------------------------
|
||||
|
||||
- début des langages vers les années 1950 (A0, Fortran(impératif),
|
||||
Lisp(impératif et fonctionnel), Cobol)
|
||||
- années 60 : Simula (classes), CPL (compilation séparée)
|
||||
- années 70 : C (référence du langage impératif de bas niveau), Pascal
|
||||
(procédures), Smalltalk (programmation orientée objects), Prolog
|
||||
(programmation logique), Scheme (programmation fonctionnelle pure), Modula,
|
||||
C++, Ada, Turbo Pascal, Common Lisp, Eiffel (programmation par contrats)
|
||||
- années 80 : ML, CAML (langages fonctionnels)
|
||||
- années 90 : Perl, Python, Ruby (languages de scripting multi-paradigmes)
|
||||
Haskell (fonctionnel pur), Lua, Delphi, Java (orienté objet, machine
|
||||
virtuelle), PHP (impératif, dédié au web), Erlang (fonctionnel+
|
||||
programmation concurrente), javascript (orienté web, objets par
|
||||
prototypage), OCaml (multi-paradigme, fortement typé, orienté sécurité,
|
||||
programmation générique, fonctionnelle et objets, modulaire et fonctorielle)
|
||||
- 2009 : go (google, compilé, typage statique, objets par prototypage,
|
||||
prgrammation concurrente), Rust (fondation mozilla, multiparadigme, programmation concurrente)
|
||||
|
||||
Les langages actuellement les plus utilisés dans le monde de l'entreprise sont :
|
||||
|
||||
- javascript/NodeJS (70% du code dans le dépôt github) mais victime de son
|
||||
succès (chaos complet des librairies)
|
||||
- le go est de plus en plus utilisé, c'est **le** langage qui monte
|
||||
actuellement
|
||||
- Python, Ruby, lua, autres langages de scripting (de plus en plus utilisés)
|
||||
- PHP, Java (stagnants)
|
||||
- C, C++ (de moins en moins utilisés)
|
||||
|
||||
Approche par typologie des langages
|
||||
-----------------------------------
|
||||
|
||||
- **A0 (1954)** : possibilité de découpage de programmes en
|
||||
sous-programmes ;
|
||||
|
||||
- **ALGOL (1958)** : concept de bloc de code (pas forcément nommé) et d'imbrication
|
||||
de blocs de code ;
|
||||
|
||||
- **C (1971)** : syntaxe claire et simple, programme fortement structuré ;
|
||||
|
||||
- **C (1980)** : le **code objet**, qui consiste à essayer de faire fonctionner
|
||||
un seul jeu d'instructions sur des machines différentes. Avant, le code
|
||||
d'assemblage dépendait du processeur, donc il n'y avait pas un seul et unique
|
||||
jeu d'instructions ;
|
||||
|
||||
- **1980** : déploiement et succès des langages à objets ;
|
||||
|
||||
- **1983** : turbo pascal (Borland) qui fut le tournant du C,
|
||||
propose un IDE (Environnement de Développement Intégré).
|
||||
aujourd'hui le turbo pascal a pratiquement disparu mais pas totalement,
|
||||
il est soutenu par une communauté open source autour de **Lazarus** ;
|
||||
|
||||
- **depuis les années 90** : deux grands groupes de langages. Les langages à
|
||||
objets, et les langages fonctionnels. Les deux mondes s'interpénètrent (les
|
||||
avancées actuelles du web, les microservices (Erlang, Haskell),
|
||||
viennent du monde fonctionnel, le NoSQL, etc).
|
||||
Les grandes avancées architecturales (système d'exploitation, linux, etc...)
|
||||
viennent du monde de l'impératif.
|
||||
|
||||
|
||||
Approches par modèles de programmation
|
||||
--------------------------------------
|
||||
|
||||
- **le mécanisme d'exceptions** : il est possible de rompre l'exécution normale d'un
|
||||
programme à un endroit et de la reprendre à un autre endroit du programme prévu à
|
||||
cet effet. Ce mécanisme permet de gérer les situations exceptionnelles.
|
||||
|
||||
- **le paradigme impératif** : les entrées-sorties, les modifications physiques de
|
||||
valeurs et les structures de contrôle itératives sont possibles.
|
||||
|
||||
- **le paradigme fonctionnel** : manipule les fonctions comme étant des valeurs du
|
||||
langage. Celles-ci peuvent être utilisées en tant que paramètres d'autres fonctions
|
||||
ou être retournées comme résultat d'un appel de fonction.
|
||||
|
||||
- **le paradigme objet** : La représentation du programme colle à la réalité en
|
||||
reproduisant des entités relativement proches des objets réel. Attention, le piège
|
||||
est de croire qu'il s'agit *du* paradigme universel puisqu'il reproduit en miroir le
|
||||
réel. **C'est en fait un processus d'abstraction comme un autre**.
|
||||
|
||||
Sûreté du langage, typage
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Tri par ordre de sûreté croissant :
|
||||
|
||||
0. typage très faible (presque inexistant aujourd'hui) : 42 == "42" == 42.0...
|
||||
1. typage dynamique faible : (javascript) (possibilité de changer le prototype
|
||||
d'un objet pendant l'éxécution du programme, c'est la fête on peut faire
|
||||
n'importe quoi)
|
||||
2. typage dynamique fort inféré par le comportement (behavior, duck typing)
|
||||
(python, ruby, PHP) Le contenu de la variable détermine le choix du typage
|
||||
`var = 0 -> type int`
|
||||
3. typage statique déclaré fort (Java)
|
||||
`int var = 0 ;` (pas mal mais super lourd, pas **agile** du tout)
|
||||
4. langages à types statiques muni d'un moteur d'inférence de types (Ocaml)
|
||||
sûreté d'exécution, agilité, sécurité.
|
||||
|
||||
|
||||
La syntaxe, la lisibilité
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Importance de la lisibilité (notamment par rapport aux méthodes agiles).
|
||||
|
||||
- courte (python)
|
||||
- verbeuse (C)
|
||||
- l'importance des mots clef du langage
|
||||
- délimiteur de phrase, de blocs (parenthèses, accolades, tabulations, blocs...)
|
||||
|
||||
Langages compilés ou interprétés ?
|
||||
-----------------------------------
|
||||
|
||||
- **le typage statique** : la vérification de la compatibilité entre les types des
|
||||
paramètres formels et des paramètres d'appel est effectuée au moment de la
|
||||
compilation du programme. Dès lors, il n'est pas nécessaire de faire ces
|
||||
vérifications durant l'exécution du programme ce qui accroît son efficacité. En
|
||||
outre, la vérification de type permet d'éliminer la plupart des erreurs introduites
|
||||
par maladresse ou étourderie et contribue à la sûreté de l'exécution.
|
||||
|
||||
- **le typage dynamique** : la vérification de la compatibilité entre les types des
|
||||
paramètres formels et des paramètres d'appel est effectuée au moment de l'exécution
|
||||
ou de l'appel à certaines parties de codes du programme.
|
||||
|
||||
- **le polymorphisme paramétrique** : une fonction ou un objet qui n'explore pas la
|
||||
totalité de la structure d'un de ses arguments accepte que celui-ci ait un type non
|
||||
entièrement déterminé. Ce paramètre est alors dit polymorphe. Cette particularité
|
||||
permet de développer un code générique utilisable pour des structures de données
|
||||
différentes tant que la représentation exacte de cette structure n'a pas besoin
|
||||
d'être connue par le code en question. L'algorithme de typage est à même de faire
|
||||
cette distinction.
|
||||
|
||||
- **l'inférence de types** : le programmeur n'a besoin de donner aucune information
|
||||
de type à l'intérieur de son programme. Le langage se charge seul de déduire du code
|
||||
le type le plus général des expressions et des déclarations qui y figurent. Cette
|
||||
inférence est effectuée conjointement à la vérification, lors de la compilation du
|
||||
programme.
|
||||
|
||||
Les grands paradigmes de programmation
|
||||
---------------------------------------
|
||||
|
||||
Le paradigme des objets
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- 1962 (SIMULA) : premières notions de classes ;
|
||||
|
||||
Pui, une dizaine d'années plus tard :
|
||||
|
||||
- C++ : intégration des classes pour le C ;
|
||||
- turbo pascal : intégration des classes pour le pascal ;
|
||||
|
||||
Tous les langages actuels ont intégré des traits objets mais de manière très
|
||||
différentes :
|
||||
|
||||
- perl (1987)
|
||||
- python (1991)
|
||||
- Ruby (1993)
|
||||
|
||||
- L'implémentation des objets en python est très proche des notions initiales de
|
||||
classes issues du Smaltalk et présente une tentative très intéressante
|
||||
d'unification des objets et des types depuis python 2.2 ;
|
||||
|
||||
- Java (1995) : très grosse réussite industrielle en surfant sur la vague de la
|
||||
programmation objet, et des machines virtuelles, mais en fait et avec le recul,
|
||||
doté d'un support objet lourd et alambiqué.
|
||||
Le monde Java est lourd, avec des outils consommant beaucoup de mémoire et
|
||||
qui ne satisfont pas à la règle du KISS (Keep It Simple, Stupid) ;
|
||||
|
||||
|
||||
Les supports objets sont riches et variés,
|
||||
|
||||
- objets obligatoirement construits pas des classes (Java, C++, ...)
|
||||
- objets sans définition de classes (javascript, Ocaml, go, rust)
|
||||
- langages à attributs (python)
|
||||
- langages ou le type des objets est défini par leur classe (python, ruby)
|
||||
- langages ou le type des objets est différent du type de leur classe (Ocaml)
|
||||
- objets sans classes mais construits par des prototypes (javascript)
|
||||
- construction d'objets possibles objets sans classe du tout (Ocaml)
|
||||
- encapsulation des attributs des objets (Java, Ocaml, C++, PHP)
|
||||
- pas d'encapsulation des attributs (python, ruby, javascript...)
|
||||
|
||||
Le paradigme impératif
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Un programme est une suite d'états de la mémoire de l'ordinateur,
|
||||
c'est la suite logique des machines de Turing.
|
||||
La plupart des programmeur aujourd'hui raisonnent suivant ce paradigme,
|
||||
et ont une très faible visibilité par rapport aux autres paradigmes existants.
|
||||
Seuls les programmeurs cultivés sont aujourd'hui capable de raisonner
|
||||
suivant différents paradigmes, ce sont des programmeurs chevronnés et
|
||||
cultivés.
|
||||
|
||||
Le paradigme fonctionnel
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
La notion de fonction que possède sous une forme ou une autre la plupart des
|
||||
langages est empruntée aux mathématiques et non à l'électronique. D'une manière
|
||||
générale, les langages substituent des modèles formels aux conceptions purement
|
||||
calculatoires. Ils y gagnent en expressivité. Certains langages fondent leur
|
||||
paradigme de programmation sur l'abstraction entrée-traitement-sortie, donc sur le
|
||||
**mathème fonctionnel** et pas sur la boite noire électronique. La fonction
|
||||
mathématique apporte un niveau opératoire dans le traitement de l'information.
|
||||
|
||||
|
||||
Approche par fonctionnalités
|
||||
----------------------------
|
||||
|
||||
Plusieurs domaines de l'informatique on proposé/imposé des méthodologies,
|
||||
des manières de faire. Ces modèles de programmation on fortement influencé
|
||||
en retour les langages. On reconnaît aujourd'hui :
|
||||
|
||||
- Le modèle client-serveur
|
||||
- Le modèle de programmation concurrente (exécution de processus légers, threads) :
|
||||
- Le modèle de développement d'une application de bureau (MVC, ergonomie d'interface)
|
||||
- Le modèle de développement web (communiquer sur le réseau Internet, API
|
||||
REST, microservices...)
|
||||
- Le modèle de programmation système et réseau
|
||||
- le modèle **Dev Ops** et les méthodes de développement virtualisés
|
||||
- les langages présentant des **fonctionnalités agiles**
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
La programmation modulaire
|
||||
==========================
|
||||
|
||||
Structuration d'un programme
|
||||
-----------------------------
|
||||
|
||||
La réalisation d'applications importantes oblige le programmeur ou l'équipe de
|
||||
développement à se poser des questions d'organisation et de structuration.
|
||||
Aujourd'hui, on dispose de deux grands modèles d'organisation dont les avantages et les
|
||||
particularités sont distincts.
|
||||
|
||||
La modularité
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Les données et les traitements sont regroupés au sein d'une même entité à deux
|
||||
facettes : d'un côté le code proprement dit, de l'autre son interface. La
|
||||
communication entre modules s'effectue via leur interface. La description d'un
|
||||
type peut être masquée en n'apparaissant pas dans l'interface du module. Ces
|
||||
types de données abstraits facilitent les modifications d'implantation à
|
||||
l'intérieur d'un module sans affecter les autres modules qui s'en servent. De
|
||||
plus, les modules peuvent être paramétrés par d'autres modules augmentant
|
||||
ainsi leur réutilisabilité.
|
||||
|
||||
Le paradigme objet
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Les descriptions des traitements et des données sont regroupées dans des
|
||||
entités appelées **classes**; un objet est une instance (valeur) d'une classe.
|
||||
La communication entre objets est réalisée par envoi de message, l'objet
|
||||
receveur détermine à l'exécution (liaison retardée) le traitement
|
||||
correspondant au message. En cela, la programmation objet est dirigée par
|
||||
les données. La structuration d'un programme provient des relations entre
|
||||
classes, en particulier l'héritage permet de définir une classe par extension
|
||||
d'une autre.
|
||||
|
||||
Comparaison entre les deux paradigmes
|
||||
-------------------------------------
|
||||
|
||||
Il y a dualité entre ces deux modèles.
|
||||
|
||||
- On ne peut pas augmenter les composants d'un type dans un module (pas
|
||||
d'extensibilité des données), mais on peut ajouter de nouveaux traitements
|
||||
(extensibilité des traitements) sur ces données.
|
||||
|
||||
- En objet, on peut ajouter des sous-classes à une classe (extensibilité des
|
||||
données) pour traiter des nouveaux cas, mais on ne peut pas ajouter de nouveaux
|
||||
traitements visibles de la classe ancêtre (pas d'extensibilité des traitements).
|
||||
|
||||
**La combinaison des deux paradigmes offre de nouvelles extensibilités pour les
|
||||
traitements et les données.**
|
||||
|
||||
Loading…
Reference in New Issue