| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This makes a makefile-driven developer workflow nicer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* trying to build emscriptenPackages not all fail
* reading the console.log it turns out python executable is not in place and that is why emconfigure didnt work
* backup commit
* much more targets are compiling now
* added common revisioning
* revision bump to 1.37.36 (not tested)
* fixed xmllint
* forcing unit testing, will implement the tests after i get home
* json_c test working
* added tests
* tiny fixes
* added documentation
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve beam docs:
* correct spelling
* update per pandoc changes
* capitalize titles
* capitalize BEAM throughout and use "the BEAM" when referring to the virtual machine.
* tweak grammar and phrasing
* reformat build-tools-rebar3 section
* add more links
* re-wrap <para>s
Also update <programlisting>s
* normalize whitespace
* don't double quote homepage
* use $ in all shell snippets
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| | |
See 0804f67024f21a75a710e41423561cc0d3472e2f.
|
| |
| |
| |
| | |
fixes #18609
|
| |
| |
| |
| |
| |
| | |
* add epub for nixpkgs manual ( #15575 )
* change epub filename (interpreted as title & author by some epub readers)
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
- Rewrite current documentation
- Add introduction/tutorial
- Convert to markdown
|
| |
|
|
|
|
|
|
| |
- Rewrite current documentation
- Add introduction/tutorial
- Convert to markdown
|
|
|
|
| |
also fixes #13243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What I missed when I began using Nix and NixOS was a clear overview of
how packages, channels, Hydra, the master branch and updates to channels
relate to each other.
I've noticed I am not the only one, given the amount of times these
questions pop up.
For now I propose to include this in the Nixpkgs manual, since this
seems to be the best fit. However, I think it would be good to include
this in either a new manual, i.e., a user manual, or an 'official'
tutorial.
|
|
|
|
|
|
| |
I also modified the nesting approach in haskell docs
to allow more uniform handling of markdown -> docbook conversions.
/cc #11308.
|
|
|
|
|
|
|
|
| |
There's no change in content except for amending the title of the
section to mention "frameworks", as e.g. I don't consider Qt a language,
and it's likely there will be more of similar cases in future.
To be certain, I checked diff of the generated HTMLs.
|
|
|
|
|
|
| |
Editing Docbook is no fun, IMHO, so I'd rather store the Haskell
documentation in Markdown format and use Pandoc to convert that into
Docbook as part of the build process.
|
| |
|
| |
|
|
|