expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2024-11-22 07:11:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

url updates

Browse Source
This commit is contained in:
Philip Sargent 2021-04-10 19:21:45 +01:00
parent 900f120de1
commit 6d88ff8d76
6 changed files with 80 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
cave_data/1623-142.html
View File

@ -22,7 +22,7 @@
</entrance>
<explorers></p><ul><li>CUCC 1982-85</li><li>Arge/CUCC 1996</li></ul><p></explorers>
<underground_description>Yet another entrance to <a href="41.htm">Stellerwegh&ouml;hle</a>, with two points of connection, and also the first point of connection with Schwabenschacht, a similar cave explored by <a href="http://arge.itvd.uni-stuttgart.de/">Arbeitsgemeinschaft H&ouml;hle und Karst Grabenstetten e.V.</a>. 142 contains a very large chamber, imaginatively named <b>The Big Chamber</b> reached by a 34m pitch from a point adjacent to the connection. A <a href="41/off41.htm#ent142">full description</a> of 142 (but not 78) is one of the components of the Stellerwegh&ouml;hle guidebook, just an overview is given here.</p><p>Note: With apparent perversity, the Austrians have numbered this as 115e in their Kataster. This is likely to give rise to immense confusion in the long term as more caves are connected, and numbers on entrances cannot readily be altered (owing to the obscurity of their location and inaccessibility from within the system).</p><p>After an initial small tube, the cave opens into passages very similar to those in Schwabenschacht and the upper levels of Stellerwegh&ouml;hle. Descent of some of the steep ramps to the right of the main way on may provide further connections into the main cave (and one may have already done so). However, staying high leads through tubes to an inobvious junction. Left is the connection to 78, whilst right leads immediately to the head of a pitch into the <b>Big Chamber</b> - a popular name in the system. A route from this chamber leads to the foot of an 18m pitch in the entrance series of <a href="41.htm">Stellerwegh&ouml;hle</a>, and a more obscure route through boulders from the head of the Big Chamber pitch leads to the same place.</underground_description>
<underground_description>Yet another entrance to <a href="41.htm">Stellerwegh&ouml;hle</a>, with two points of connection, and also the first point of connection with Schwabenschacht, a similar cave explored by <a href="/others/arge/index.html">Arbeitsgemeinschaft H&ouml;hle und Karst Grabenstetten e.V.</a>. 142 contains a very large chamber, imaginatively named <b>The Big Chamber</b> reached by a 34m pitch from a point adjacent to the connection. A <a href="41/off41.htm#ent142">full description</a> of 142 (but not 78) is one of the components of the Stellerwegh&ouml;hle guidebook, just an overview is given here.</p><p>Note: With apparent perversity, the Austrians have numbered this as 115e in their Kataster. This is likely to give rise to immense confusion in the long term as more caves are connected, and numbers on entrances cannot readily be altered (owing to the obscurity of their location and inaccessibility from within the system).</p><p>After an initial small tube, the cave opens into passages very similar to those in Schwabenschacht and the upper levels of Stellerwegh&ouml;hle. Descent of some of the steep ramps to the right of the main way on may provide further connections into the main cave (and one may have already done so). However, staying high leads through tubes to an inobvious junction. Left is the connection to 78, whilst right leads immediately to the head of a pitch into the <b>Big Chamber</b> - a popular name in the system. A route from this chamber leads to the foot of an 18m pitch in the entrance series of <a href="41.htm">Stellerwegh&ouml;hle</a>, and a more obscure route through boulders from the head of the Big Chamber pitch leads to the same place.</underground_description>
<equipment></equipment>
<references></references>
<survey>CUCC plan from surveys 1982-1985, here in several sections:</p><ul><li><a href="41/142ent.png">Entrance area</a></li><li><a href="41/142bc.png">Big Chamber</a></li><li><a href="41/142-41.png">Stellerweg connection</a>...</li></ul><p></survey>

14
handbook/computing/todo-styles.css
View File

@ -66,14 +66,24 @@ dd {
margin-left: 1.0em;
}
dd:before {
li {
font: 18px Calibri, sanserif;
font-weight: normal;
color: 6083BF;
list-style-type: None;
line-height: 1.3;
margin-left: 1.0em;
}
li:before, dd:before {
content: "» ";
font-weight: bold;
color: red;
}
/* Default State */
dt {
summary, dt {
font: 20px Calibri, sanserif;
font-weight: bold;
color: 6083BF;

26
handbook/computing/todo.html
View File

@ -35,20 +35,22 @@ If a heading is in italics, then there are hidden items.
<p>To see the "data maintenance" and "survey data-entry" to-do lists, go to <a href="todo-data.html">the other TO-DO list</a>
<h3>Process Documentation</h3>
<dl>
<dt><!--2020-03-26 psargent-->Wallets and new-cave</dt>
<dd><!--2020-03-26 psargent-->Explain how to link a new cave into the other caves in
<details><summary><!--2020-03-26 psargent-->Wallets and new-cave</summary>
<li><!--2020-03-26 psargent-->Explain how to link a new cave into the other caves in
troggle filesystem</dd>
<dd><!--2020-03-26 psargent-->Explain how to add photos with the correct URL format to sub-HTML files attached to New Caves</dd>
<dt><!--2020-04-13 psargent-->svx check</dt>
<dd>explain command line to run on newly typed survex file to check for format errors '$cavern xxxx.svx'
<dd>explain when to use svxtrace.py <a href="troggle/scriptscurrent.html">current scripts</a>
<dd>Making an svx - explain how to make link to *ref to wallet folder
<dd>explain how to put stuff in the wallet folder and how to look at expofiles/photos/xml/
<dd>Add to user data manual how to upload to expofiles - in the "survey manual"
<dd>Add in description of *where* to put the drawings files
</dl>
<li><!--2020-03-26 psargent-->Explain how to add photos with the correct URL format to sub-HTML files attached to New Caves</dd>
</details>
<details><summary><!--2020-04-13 psargent-->svx check</summary>
<li>explain command line to run on newly typed survex file to check for format errors '$cavern xxxx.svx'
<li>explain when to use svxtrace.py <a href="troggle/scriptscurrent.html">current scripts</a>
<li>Making an svx - explain how to make link to *ref to wallet folder
<li>explain how to put stuff in the wallet folder and how to look at expofiles/photos/xml/
<li>Add to user data manual how to upload to expofiles - in the "survey manual"
<li>Add in description of *where* to put the drawings files
</details>
<h3>Surveys data entry documentation</h3>
<dl>
<dt>Write code to automatically extract ref info about wallets from tunnel xml files

8
handbook/geartape.html
View File

@ -9,8 +9,8 @@
<h1>Gear tape colours for Expo 2020</h1>
<h3>TO BE UPDATED FOR 2020</h3>
<h1>Gear tape colours for Expo 2021</h1>
<h3>TO BE UPDATED FOR 2021</h3>
<p>Geartape lists for CUCC and previous expo years
<ul>
@ -258,8 +258,8 @@ Grey</span>, <span style="border: thin solid black; padding: 0.3ex 0.5em; color:
on a particular combination of colours of electrical insulation tape, and label
<em>absolutely everything</em> you own with the stuff. The table above shows combinations already taken.
For other CUCC colour combinations already in use see <a
href="https://camcaving.uk/Documents/Legacy/Gear%20Tape%20Colours%20-%20Cambridge%20University%20Caving%20Club.htm">CUCC gear tape</a> (current gear tape page offline, so this is the legacy page).
For other CUCC colour combinations already in use see <a href="https://camcaving.uk/Gear/Tape/">CUCC current colours</a> and, if you are really keen on being unique, also check out <a
href="https://camcaving.uk/Documents/Legacy/Gear%20Tape%20Colours%20-%20Cambridge%20University%20Caving%20Club.htm">older cavers' gear colours</a>.
<p> Tape

4
handbook/travel.html
View File

@ -141,9 +141,9 @@ http://fahrplan.oebb.at</a>.
This path is on the other side of the river and is shady and cool in hot weather. The path rejoins the road about 250m from Staudnwirt.</p>
<p>There is a <a href="http://ausseerland.salzkammergut.at/detail/article/15763-narzissenjet.html">taxi service</a>
<p>There was a 'Narzissenjet' taxi service</a>
for the Bad Aussee region with standard stopping places including the train staton and the Staudnwirt Gasthof.
It cost &euro;12 one-way in 2017.
It cost &euro;12 one-way in 2017. It seems to have died and we should ask the Gasthof whether there is an alternative.
Here is
<a href="https://ausseerland.salzkammergut.at/fileadmin/_processed_/a/2/csm_Narzissenjetfolder_180410_Karte_620196b749.jpg">
a map</a> of the stopping points: the Gasthof is #14 and the train station is #27.</p>

71
handbook/troggle/trogdjangup.html
View File

@ -56,8 +56,8 @@
</table>
</div>
<h4>Major, minor and releases</h4>
<p>Django release 1.11.29 is major-version 1, minor-version 11, and patch-release 29. 1.11 is the "feature release".
<p>Things <em>will break</em> between <a href="https://docs.djangoproject.com/en/dev/internals/release-process/">django minor-versions</a> (feature releases) which come out every 8 months.
<p>Django release 2.2.20 is major-version 2, minor-version 2, and patch-release 20. 2.2 is the "feature release" and patch releases within each feature release are not meant to break anything. They are just to fix bugs.
<p>Things <em>will break</em> between <a href="https://docs.djangoproject.com/en/dev/internals/release-process/">feature releases</a> which come out every 8 months.
<h4>Django plugins ("apps")</h4>
<p>Documentation for the plugins is highly variable and plugin projects, being run by volunteers, can just die unexpectedly. For django-registration there are two sources of current information:<br />
@ -84,20 +84,21 @@
python manage.py validate -v 3 --traceback<br />
django-admin check <br />
python manage.py test -v 3 --traceback</var>
<li>Use the <em>highest release number</em> when upgrading between minor-versions of django. <br />So we went from 1.8.19 to 1.9.13 to 1.10.8 to 1.11.29 . Next will be 2.0.13, then 2.1.15 and then 2.2.15 .
<li>Use the <em>highest release number</em> when upgrading between minor-versions of django. <br />So we went from 1.8.19 to 1.9.13 to 1.10.8 to 1.11.29 to 2.0.13 to 2.1.15 and then 2.2.19 .
<li>Use the django 'check' maintenance system at the most verbose setting at each release<br />
<var>troggle$ python manage.py check -v 3 --deploy</var><br>
<var>troggle$ python -Wall manage.py check</var><br>
<li>Use our test suite (and if you see errors, run it with <var>-v 3</var>)<br />
<var>troggle$ python manage.py test [-v 3]</var><br>
<li>Read all the release notes for <em>all</em> the intermediate releases. So from 1.1.29 we will read <a href="https://docs.djangoproject.com/en/3.0/releases/">14 sets of notes</a>: for <a href="https://docs.djangoproject.com/en/3.0/releases/2.0/">2.0</a>, 2.0.1, 2.0.2... up to 2.0.13 .
<li>Read all the release notes for <em>all</em> the intermediate releases. So from 1.1.29 we read <a href="https://docs.djangoproject.com/en/3.0/releases/">14 sets of notes</a>: for <a href="https://docs.djangoproject.com/en/3.0/releases/2.0/">2.0</a>, 2.0.1, 2.0.2... up to 2.0.13 .
<li>Seriously learn how to use the traceback webpage produced by django when a page crashes. There is a full record of every variable value hidden in there.
<li>You will be doing a lot of local testing just on your development machine. The default is to use the webserver built into Django: <var>python manage.py runserver 0.0.0.0:8000 -v 3</var>. Alternatively you can install and use gunicorn:
<var><a href="https://docs.gunicorn.org/en/stable/design.html">gunicorn</a> --reload -w 9 -b :8000 wsgi</var>. the '-w' flag is for the number of worker threads and should be 2n+1 where n is the number of cpu cores on your machine.
</ol>
<p>The individual releases within a minor version don't break anything but do fix bugs. So if you are on 1.10.x there is no point in getting 1.11.1 to work and you should go straight to 1.11.29 (29 is the highest release number in minor version 1.11).
<p><var>--deploy</var> gives django warnings about security issues in your settings as well as django deprecation warnings.<br>
<var>-Wall</var> is a standard python option and gives warnings of deprecated python features used by django and all the current plugins. So it tells us that django 1.11.29 is using a deprecated python language feature which will be removed from the language in python 3.9 (in fact 1.11.29 is incompatible with python 3.8 too but we didn't get a warning about that).
<h3>Deprecation warnings and python versions</h3>
<p>The individual releases within a minor version don't break anything but do fix bugs. So if you are on 1.10.x there is no point in getting 1.11.1 to work and you should go straight to 1.11.29 .
<p><var>check --deploy</var> gives django warnings about security issues in your settings as well as django deprecation warnings.<br>
<var>-Wall</var> is a standard python option and gives warnings of deprecated python features used by django and all the current plugins. So it tells us that django 1.11.29 is using a deprecated python language feature which will be removed from the language in python 3.9 . Python version compatibilities are documented at the top of each x.0 release note. From Django 3.0 it requires python 3.6.
<h3>The upgrade process</h3>
<ol>
@ -141,31 +142,53 @@
<li>run the script <var>./pre-run.sh</var> to clean up everything before the next round of tests.
</ol>
<h3>Django dependencies</h3>
<p>You can upgrade the version of python installed within pip venv but not downgrade. So get that first venv installed right.
<p>Here is example of installed (Version) and most-recent-available (Latest) verisons of pip installations.
<pre><code>$ pip list -o
Package Version Latest Type
------------------- ------- ------ -----
Django 1.11.29 3.2 wheel
docutils 0.16 0.17 wheel
Pillow 7.2.0 8.2.0 wheel
pytz 2020.1 2021.1 wheel
setuptools 45.2.0 54.2.0 wheel
Unidecode 1.1.1 1.2.0 wheel</code></pre>
<pre><code>Package Version Latest Type
---------- ------- ------ -----
Django 2.2.19 3.2 wheel
docutils 0.14 0.17 wheel</code></pre>
<p>This only gives any output for packages which are not the most recent. To see what is actually installed use
<pre><code>$ pip freeze
confusable-homoglyphs==3.2.0
Django==1.11.29
docutils==0.16
Pillow==7.2.0
pytz==2020.1
Unidecode==1.1.1</code></pre>
<p>To upgrade pip istelf, do <var>$ pip install --upgrade pip</var>
<p>We will not need to anything until we move from django 2.2.15+ to 3.2+ which <a href="trog2030.html">we may never do</a>.
Django==2.2.19
docutils==0.17
Pillow==8.2.0
pytz==2021.1
sqlparse==0.4.1
Unidecode==1.2.0</code></pre>
Although the above all work fine, on debian <var>buster</var> we are actually using the standard installs which are older:
<pre><code>$ pip freeze
confusable-homoglyphs==3.2.0
Django==2.2.19
docutils==0.14
Pillow==5.4.1
pytz==2019.1
sqlparse==0.2.4
Unidecode==1.0.23</code></pre>
<p>To upgrade pip istelf, do <var>$ pip install --upgrade pip</var>
<h3>Django database dependencies</h3>
<p>On the expo server we run MariaDB as the database which has its own dependencies. In particular
<pre><code>mysqlclient==1.3.10
</code></pre>which is technically incompatible with Django 2.2 which requires 1.3.13. This incompatibility is a policy choice by the Django team. Wookey ran the Django system tests with this (April 2020) and it works fine.
<h4>To run Django's system test suite:</h4>
Follow the instructions in the "Unit tests" section installed locally at docs/internals/contributing/writing-code/unit-tests.txt, published online at <a href="https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#running-the-unit-tests">docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/</a>
This involves running <var>git clone</var> on the django source repo to download the tests. We hope we never have to do this again but in case we get incomprehensible bugs in future, we should be prepared to do so.
<p>Current upgrade status is documented: <a href="trogstatus.html">here</a>.
<hr />
<p>We should not need to anything until we move from django 2.2 LTS to 3.2 LTS which <a href="trog2030.html">we may never do</a>.
<p>Current upgrade status is documented: <a href="trogstatus.html">here</a>.
<p>
Go on to: <a href="trogarch.html">Troggle architecture</a><br />
Return to: <a href="trogintro.html">Troggle intro</a><br />
Troggle index: