@Eduardo Mercovich (él)

One more humdrum piece of advice: backups!

A version control repository is not a replacement for backups.  Repos need backing up too.

It achieves one function that backups help with, that's getting back to previous versions.  

However, if it's on the same computer or drive, it does not help with hardware failure / loss of the computer / catastrophic operator error.

(It's also possible to ruin your repository if you're 'clever' enough.  I've been this clever in the past. Not if you stick to absolutely simple things as per my recommendation, tho.)

The usual recommended minimum is the original plus two backup copies.  Neither backup should be on the same hardware, and one should be in a different location (e.g. in the cloud, emailed regularly to a friend).

Backup regularly.  Every day, or more frequently if you're doing a lot of work.  How much lost work can you easily shrug off if your computer dies?

And the backups should be checked occasionally to make sure you really are backing up.

A remote repository (e.g. codeberg) counts as one backup, but only if your push changes to it regularly.

(Sorry if I'm telling you what you already know, with this and my last message about git.  However, in the case of backups it's common for people to be terrible about it, even if they know better.  For example, while I backup semi-regularly, the 'other location' is just a different room, which doesn't help if the house burns down.  So some degree of exhoration/nagging seems appropriate...)

#tem25 #backups #versioncontrol

@Eduardo Mercovich (él)

This is a lot of thanks for a modicum of effort, during which I improved my elisp — and it does very little to address the state of the world, alas!

Can I suggest you put your thesis under version control as soon as you can, if it's not already?  

The day you realise your sweeping edits were the wrong idea it will save your hide, and it's often useful less dramatically on other occasions.

For a single document being worked on by a single person, you really need very little knowledge of git.  Just three very simple things: how to set it up, how to store changes, and how to retrieve a previous version.  You don't even really need to know how to retrieve to start with — you could happily leave this until later, even deferring this until you really need it.  You could even in a pinch get someone else to do it.  Whereas they can't help you if you don't have previous versions in a repository!

Setting things up

- navigate to the directory/folder your thesis is in, and

git init --initial-branch main
git add thesis.org
'git init' sets up an empty repository.  you don't need the --initial-branch argument but if you don't git will call it 'master' which some find offensive.  As you may be making this public you may as well avoid this controversy.

(You do not need to worry about branching at all - I can't see why you'd want to branch your thesis.  But there's always at least one branch and things like codeberg will display its name.)

'git add' is perhaps a little misleading.  The repository is still empty at this point, you've just told git to track the file 'thesis.org' and store changes to it when you commit - which is the next step.


Storing changes

git commit -m "a message describing very briefly what changed"
This stores all changes to the files git is tracking to the repository.  After the first commit the repository will now have a copy of thesis.org in it, in the state it was when you committed it.

'-m' is for 'message' naturally.

"initial commit" is a traditional first commit message. Other examples might be "fixed references in chapter 3", "incorporated jamie's code" etc.

I recommend committing pretty frequently - maybe every day!

And that's all you need to know!

(I'm assuming you have git installed already.  Let me know if you need help with that.

Also, I know you want to use magit but I've barely ever used it, and for these very simple use cases I think it's worth learning to use command line git.  It means you can understand what others are talking about, and also cope if magit isn't available).

@Eduardo Mercovich (él) #tem25 #git #versioncontrol

Dear @jamie
Thanks a lot for your time and attention (and code, of course). ;)
I am about to go to a Conference in Helsinki and will be back on the 30th, so no hurry. I will try to move the thesis #tem25 in the in-between times but I'm afraid there won't be much of those in the next days. ;D
And, for sure, will try your code once I'm there and will report back. :)))
Again, thanks a lot. Your sharing helps us all to keep hope in people and work towards a better world in these dark times.
Best.

I'll either rewrite this to be easier to understand or provide more commentary or both in the near future.   An org-mode literature program maybe?

#tem25 #elisp

@Eduardo Mercovich (él)

Well, I got this much working, which is sort of the crux of the problem.  It takes a list of pairs and a function and applies the function repeatedly to the cdrs of the pairs that share the same car.

Roger has shown an expanded version of the table where the groups have been put against the values that apply to them.  The last two columns of that table should be able to be turned into an appropriate list easily enough - I have not attempted this yet.

I'm in two minds about this as a solution for you.  

On the one hand it's short, and has some general applicability beyond the stated problem.  

On the other, I may be being a bit too clever - not quite 'week 1 of Lisp' material I suppose. Sticking to explicit iteration and solving the specific problem only would be more digestible.  But this is the concrete thing that I got to first.

   On the other other hand - I'm wondering whether there are library functions available to do this with fewer lines that I'm ignorant of.


Plus the use of the lambda in the application is a bit clunky - might be nicer to just pass + in (could just put in another layer of wrapping to do this).  

And the function names might need some further thought...

But I thought I'd table it anyway — might be good to see some progress and perhaps it will inspire others to do better :-)

(defun assoc-replace (new alist)
  "non-destructively replace the alist element with new, where the keys are equal"
  (cl-substitute-if new
            (lambda (x)
              (equal (car x) (car new)))
            alist))


(defun alist-acummulate-step (f alist pair)
  "lookup alist using car pair and replace the element with f applied to the cdrs of it and pair. Add pair to alist if not found."
  (let* ((key (car pair))
     (old-pair (assoc key alist)))
    (cond
     (old-pair
      (let ((result (funcall f (cdr old-pair) (cdr pair))))
        (assoc-replace (list key result) alist)))
     (t
      (cons pair alist)))))

(defun alist-reduce (f pairs alist-initial)
  "reduce using f into an alist with keys as the unique cars of pairs"
  (seq-reduce
   (lambda (x y) (alist-acummulate-step f x y))
   pairs alist-initial))
Example of use:
(alist-reduce (lambda (x y) (+ (car x) (car y))) '((a 1) (b 2) (a 3) (c 4) (b 3) (b 4)) nil)
=>
((c 4) (b 9) (a 4))


#tem25 #elisp

@Eduardo Mercovich (él)

This particular problem should be straightforward to do using elisp, particularly with Roger's suggestion of an intermediate representation.  I will try later on tonight (right now head is full of other stuff).

Sort of think I can crack out a solution quickly, but experience tells me I am (like everyone else) far too optimistic at how long it takes to code something up & I have limited time until the weekend, which might be a more realistic timeframe.

As problems get more complex or specialized, there's a point at which switching to R would make more sense — e.g. it will be easier to learn some R than try to equip elisp with extensive data reorganization or statistical abilities (which of course would be possible in principle).

But if your problems are mostly of this level of complexity, I think I agree, you may as well avoid having R as a dependency.

@Roger Schürch
#tem25