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

Troggle staus & history update

Browse Source
This commit is contained in:
Philip Sargent 2022-12-16 16:26:16 +00:00
parent fdc3947e3c
commit d971f37320
4 changed files with 31 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
handbook/troggle/trogdjangup.html
View File

@ -10,6 +10,7 @@
<h1>Upgrading Django for Troggle</h1>
<h4>Why this is difficult</h4>
<p>When django upgrades to a new version things break across the entire django package, including things which we don't conciously use but are internal dependencies within django. These were 'the way to do it' when troggle was first written for django 0.7 in 2006. So upgrading troggle to a new django version requires not just a broad beadth of knowledge across troggle, but also across the entire breadth of django itself. And the error messages are sometimes very unhelpful.
<p>Now read <a href="trogdjango.html">Django and Troggle</a> if you haven't already.
<h4>Django versions and update schedule</h4>
@ -226,6 +227,7 @@ This involves running <var>git clone</var> on the django source repo to download
<p>
Go on to: <a href="trogarch.html">Troggle architecture</a><br />
Return to: <a href="trogdjango.html">Django and Troggle</a><br />
Return to: <a href="trogintro.html">Troggle intro</a><br />
Troggle index:
<a href="trogindex.html">Index of all troggle documents</a><br />

18
handbook/troggle/trogstatus.html
View File

@ -14,18 +14,9 @@
<p>For earlier history see <a href="../website-history.html">Website history</a>.
<h4>June 2020</h4>
<p>Sam was a bit overworked in trying to get an entire university to work remotely during Covid lockdown so Philip [Sargent] started on the python2/3 conversion and got troggle on django 1.7 to work on python 3.5 and then 3.8. He then did the slog of migrating it through the django versions up to 1.11.29 - the last version before django 2.0 . 1.11.29 is an LTS (long term support) version of django. In doing this we had to retreat to python3.7 due to a django plugin incompatibility.
<p>
In the course of these migrations several unused or partly-used django plugins were dropped as they caused migration problems (notably staticfiles) and the plug-ins pillow, django-registration, six and sqlparse were brought up to recent versions. This was all done with pip in a python venv (virtual environment) on a Windows 10 machine running ubuntu 20.04 under WSL (Windows Systems for Linux) v1.
<p>Missing troggle functions were repaired and partly-implemented pages, such as the list of all cavers and their surveyed passages, were finished and made to work. The logbook parsing acquired a cacheing system to re-load pre-parsed files. The survex file parsing was completely rebuilt to reduce the excessive memory footprint. While doing so the parser was extended to cover nearly the full range of survex syntax and modified to parse, but not store, all the survey stations locations. A great many unused classes and some partly written code ideas were deleted.
<h4>July 2020</h4>
<p>Wookey upgraded debian on the server from 9 <var>stretch</var> to 10 <var>buster</var> and we got the python3 development of troggle running as the public version (with some http:// and https:// glitches) by 23rd July. <var>Buster</var> will be in-support definitely until June 2024 so we are rather pleased to be on a "not ancient" version of the operating system at last. This concided with a last tweak at improving the full cave data file import so now it runs on the development system in ~80 seconds. Which is considerably more useful than the ~5 hours it was taking earlier this year.
<h4>April 2021</h4>
<p>Lockdown has been good to troggle. During March and April Philip migrated troggle up to Django 2.2.19, excising the ancient and unused user registration system on the way. Django 2.2 LTS is a long-term stable relase which will be in-support by Django until April next year. Wookey discovered and ran the Django system testsuite on the Debian server thus enabling us to use a necessary (but obstensibly outdated) link between Django and the database MariaDB. As of April 9th troggle is now running on software which is actually 'in date'.</p>
<p>Covid lockdown has been good to troggle. During March and April Philip migrated troggle up to
<a href="../troggle/trogdjangup.html">Django 2.2.19</a>, excising the ancient and unused user registration system on the way. Django 2.2 LTS is a long-term stable relase which will be in-support by Django until April next year. Wookey discovered and ran the Django system testsuite on the Debian server thus enabling us to use a necessary (but obstensibly outdated) link between Django and the database MariaDB. As of April 9th troggle is now running on software which is actually 'in date'.</p>
<p>We plan to stick with this configuration for a year.</p>
@ -42,14 +33,15 @@ So the presure to migrate from Django is now very greatly lessened. However, see
and possible <a href="trog2030.html">migration from Django</a>.
<p>We should not need to anything until we move from django 3.2 LTS to 4.2 LTS before April 2024.
<p>We should not need to anything until we move from Django 3.2 LTS to 4.2 LTS before April 2024.
<h4>July 2022</h4>
<p>Wookey at last, after much effort, got the loser repository converted from mercurial to git, with much tidying and
history-reconfabulation. He says this will need to be done again, but it was good enough for the 2022 Expo. Also the troggle code was
changed: survex files edited on a webpage now automatically commit to git with no user involvement.
<p>Just before expo, we finished integrating the formerly-separate 'wallets' script.
So now the progress of scanning and tunneling survey data can be managed more easily. And it works on the data back to 1999 too.
So now the progress of scanning and tunneling survey data can be managed more easily. This
has turned out to be unexpectedly powerful. And it works on the data back to 1999 too.
<hr />
<img border="1" class="onright" width="150px" src='tricky-troggle.jpg' alt='git logo'/></a>
Return to: <br />

28
handbook/website-history.html
View File

@ -157,12 +157,19 @@ website, could be easily reversed.
made sense, and so wrote Troggle.
This uses Django to generate pages.
This reads in all the logbooks and surveys and provides a nice way to access them, and enter new data.
It was separate for a while until Martin Green added code to merge the old static pages and
new troggle dynamic pages into the same site. This is now the live system running everything (in 2019). Work on developing Troggle further still continues (see <a href="troggle/trogintro.html">Troggle intro</a>).</p>
<p>From the <a href="/years/2009/report.html">2009 expo report</a>:<br />
<ul>
This year's expedition also had a non-caving goal (not just drinking Gösser). Recently [since 2006] members of CUCC have started to develop a piece of software called Troggle, which aims to facilitate keeping track of logbook entries, typing up surveys, caves etc, and save time in a lot of the work that goes on behind the scenes when expo is over. This year was the first time Troggle would be tested "in the field" (well, spud hut).
</ul>
<p>After Expo 2009 the version control system was updated to a <a href="computing/onlinesystems.html#mercurial">DVCS</a> (Mercurial, aka 'hg'),
because a distributed version control system makes a great deal of sense for expo
(where it goes offline for a month or two and nearly all the year's edits happen).</p>
It was separate for a while until Martin Green added code to merge the old static pages and
new troggle dynamic pages into the same site. This is now the live system running everything (in 2022). Work on developing Troggle further still continues (see <a href="troggle/trogintro.html">Troggle intro</a>).</p>
<p>After Expo 2009 the version control system was updated to a <a href="computing/onlinesystems.html#mercurial">DVCS</a> (Mercurial, aka 'hg'),
<ul>
'because a distributed version control system makes a great deal of sense for expo
(where it goes offline for a month or two and nearly all the year's edits happen)'.
</ul></p>
<p>The site was moved to Julian Todd's seagrass server (in 2010),
but the change from a 32-bit to 64-bit machine broke the website autogeneration code,
@ -172,7 +179,7 @@ troggle, the survey data, the tunnel data. Seagrass was turned off at
the end of 2013, and the site has been hosted by Sam Wenham at the
university since Feb 2014.
<p><em>From "<a href="/expofiles/documents/troggle/troggle2020.pdf" download>
<p><em>Some text taken from "<a href="/expofiles/documents/troggle/troggle2020.pdf" download>
Troggle: a revised system for cave data management</a>", by Philip Sargent and Aaron Curtis, CUCC [with some additions]</em>.
<em>Original (2006) paper: "<a href="/expofiles/documents/troggle/troggle_paper.pdf" download>
@ -248,6 +255,15 @@ tackling the next step: thinking deeply about when we migrate from django
Enforced time at home under covid lockdown is giving us a new impetus to writing and restructuring the documentation for everything.
</details>
<h4>June 2020</h4>
<p>Sam was a bit overworked in trying to get an entire university to work remotely during Covid lockdown so Philip [Sargent] started on the python2/3 conversion and got troggle on django 1.7 to work on python 3.5 and then 3.8. He then did the slog of migrating it through the django versions up to 1.11.29 - the last version before django 2.0 . 1.11.29 is an LTS (long term support) version of django. In doing this we had to retreat to python3.7 due to a django plugin incompatibility.
<p>
In the course of these migrations several unused or partly-used django plugins were dropped as they caused migration problems (notably staticfiles) and the plug-ins pillow, django-registration, six and sqlparse were brought up to recent versions. This was all done with pip in a python venv (virtual environment) on a Windows 10 machine running ubuntu 20.04 under WSL (Windows Systems for Linux) v1.
<p>Missing troggle functions were repaired and partly-implemented pages, such as the list of all cavers and their surveyed passages, were finished and made to work. The logbook parsing acquired a cacheing system to re-load pre-parsed files. The survex file parsing was completely rebuilt to reduce the excessive memory footprint. While doing so the parser was extended to cover nearly the full range of survex syntax and modified to parse, but not store, all the survey stations locations. A great many unused classes and some partly written code ideas were deleted.
<h4>July 2020</h4>
<p>Wookey upgraded debian on the server from 9 <var>stretch</var> to 10 <var>buster</var> and we got the python3 development of troggle running as the public version (with some http:// and https:// glitches) by 23rd July. <var>Buster</var> will be in-support definitely until June 2024 so we are rather pleased to be on a "not ancient" version of the operating system at last. This concided with a last tweak at improving the full cave data file import so now it runs on the development system in ~80 seconds. Which is considerably more useful than the ~5 hours it was taking earlier this year.
<h3>More recent</h3>
<p>
For the current situation see <a href="troggle/trogstatus.html">expo systems status</a>.

3
years/2016/camping_in_tunnocksschacht.html
View File

@ -3,9 +3,10 @@
<h2>CHECC Grand Prize entry for Cambridge: camping in Tunnocksschacht, Austria</h2>
<h4>Nov 25, 2016</h4>
<p>by CavingPig (presumably Elaine)
<p>by CavingPig (Elaine Oliver)
<p>[to be added in to the logbook where appropriate.]
<p>
<b>2016-07-18</b><br />
It was decided that this year, the CUCC expo would establish an underground camp in Kraken Chamber,
Tunnocksschacht, as pushing trips to the lower leads were getting to be around 18 hours, which was bordering on
the unsafe in terms of fatigue in combination with navigating the nylon highway required to get in and out.