git checkout HEAD -- naamvanbestand

De gegevens van een programma

De $XDG_DATA_HOME base directory bepaalt de “data” directory voor applicaties.
Terugvalwaarde is $HOME/.local/share

Vuilbakstandaard

Volgens de freedesktop specificaties zit het zo:
-locatie van de “hoofd” vuilbak is vastgelegd in systeemvariabele :
$XDG_DATA_HOME/Trash

Als die (XDG_DATA_HOME) niet gedefinieerd is, is de standaardwaarde voorzien:

~/.local/share/Trash/files

Bij het maken van een desktopgebruiker, maakt het systeem een trash directory volgens de waarde in $XDG_DATA_HOME/Trash of op de standaarlocatie.

Als ik op mijn huidige systeem git diff doe, wordt het antwoord getoond in een soort tekstverwerker waarin ik handig kan scrollen, zoeken enz, en die ik verlaat met “q”.
Maar helaas, als ik daarna een andere aktie wil doen, bv een commit waarin ik als commentaar iets schrijf wat ik uit die diff haal, zie ik die niet meer.

Ik wil dus de uitvoer van diff op het scherm houden, bv voor het bestand Changes.txt:

git --no-pager diff Changes.txt

Er is ergens een stomme bug veroorzaakt, waarschijnlijk lang geleden, en de oorzaak is onduidelijk; is het met een aanpassing aan de code gebeurd, of per vergissing door even in de editor in een verkeerd bestand iets te doen bij te snelle toetsaanslagen tijdens het werk?

Hoe kan git mij helpen dat moment terug te vinden?

Log path:

git log --path

bv:
git log -- Trypo/.src/TrypoForms/FDayReq.class

Daarmee kan je al zien wanneer daar de laatste aanpassingen gedaan zijn. Maar welke?

Bv de bug bevondt zich op regel 889 en betrof missende () bij een bewerking.

Log line:

git log -L(from),(to):(path)

bv:

git log -L887,891:Trypo/.src/TrypoForms/FDayReq.class

Dit geeft me de – en + regels, en hiermee kan ik snel vinden wat er juist gebeurd is.

De online versie van de master en mijn eigen lokale versie zijn uiteengelopen.

git checkout master
Switched to branch 'master'
Your branch and 'origin/master' have diverged,
and have 11 and 1 different commits each, respectively.


Ik kan het niet eenvoudig oplossen met push of pull:


git status
On branch master
Your branch is ahead of 'origin/master' by 11 commits.
(use "git push" to publish your local commits)
'
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: .project
'
no changes added to commit (use "git add" and/or "git commit -a")
linuxuser@copyleft:~/Git/MyProject> git push
To gitlab.com:dev/myproject.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'gitlab.com:dev/myproject.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
linuxuser@copyleft:~/Git/MyProject> git pull
error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.


Ik haalde de main af in een test directory en met Kompare bekeek ik de verschillen om te checken wat er aan de hand was. Conclusie: mijn locale versie moet de nieuwe main/master worden.

Ik beveilig eerst mijn locale wijzigingen in een nieuwe branch:
(Als het over een kleine wijziging ging zou ik misschien git stash en git stash pop gebruiken)

git branch backup-mainlocal

Daarna even checken:

git status
On branch master
Your branch and 'origin/master' have diverged,
and have 12 and 1 different commits each, respectively. (...)

Ik zit nog in mijn master; gelijkzetten met de online versie:

git reset --hard origin/master
HEAD is now at efde303 Update ReadMe.txt with sourceforge tar.gz link

Ik zie de laatste wijziging daar in mijn ReadMe bestand.
Nu zijn beide versies terug gelijk:

git status
On branch master
Your branch is up to date with 'origin/master'.

en kan ik de wijzigingen toepassen uit mijn backup:

git merge backup-mainlocal
Merge made by the 'ort' strategy.
.component | 4 ++++
.gitignore | 19 +++++++++++++++++
.project | 3 ++-
.src/FMain.class | 54 +++++++++++++++++++++++++++++++++++++++++-------
.src/FMain.form | 4 ++--
...
Changes.txt | 15 ++++++++++++++
Help.txt | 2 +-
10 files changed, 441 insertions(+), 29 deletions(-)
create mode 100644 .component
create mode 100644 .gitignore

En online brengen:

linuxuser@copyleft:~/Git/MyProject/> git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 627 bytes | 627.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0), pack-reused 0
To gitlab.com:dev/myproject.git
efde303..c950ea5 master -> master

Ok nu zijn ze terug synchroon.

Ik moet een oud project oppikken dat ooit een aparte branch had waarin ik wil gaan werken, en ik moet de code up to date maken met de huidige stand.

git reset --hard origin/master

Als antwoord krijg ik:

HEAD is now at 01d4e38 fix conflicts

Ik vraag me af welke conflicts er dan zijn, want er worden er geen opgesomd. Normaal, als er conflicten zijn, wordt de aktie niet uitgevoerd, maar hier heb ik wel de bevestiging van “Head is now at ..”.

Bij nader inzien bleek “fix conflicts” de commit message te zijn van de laatse commit waar head nu op zit ….

Ik heb in een “dev” map een project “myproject” met ontwikkeling in Gambas3 op een pc met Kde-desktop.

Er is één tak van het project, branch “compat-lxde”, die ik ontwikkel op een ander toestel (Raspberry Pi) met een LXDE desktop; om de applicatie daar compatibel met die desktop te houden. Hierin neem ik bijna alles over van de “main”, behalve de dingen die niet werken in een LXDE desktop, die laat ik weg of pas ik aan.

De branches main en compat-lxde lopen dus grotendeels parrallel.

Soms wijzig ik iets op di Pi aan de lxde versie dat ook nuttig is voor main, en om dat binnen te halen wil ik ook de lxde code op mijn KDE-pc, maar op zo’n manier dat ik mij niet vergis met mijn gewone development, ik moet vermijden dat ik mijn gewone development aan het doen ben in de lxde versie bv.

Ik wil dus op mijn pc op een andere plek één bepaalde tak van mijn ontwikkeling apart bijhouden om die daar enkel te raadplegen.
Ik wil hier niet alle andere branches in hebben want die heb ik in mijn dev map, en daar werk ik ook aan.

Algemeen:
git clone -b --single-branch

Bv: als branch compat-lxde bestaat in het project:
git clone -b compat-lxde --single-branch https://gitlab.com/project/myproject.git

Ook op de Raspberry Pi kan het nuttig zijn om niet alle code binnen te halen, maar enkel de branch “compat-lxde” en bv “main” of “test”.

Nu kan ik op de pc in mijn dev directory de branches gebruiken om in te werken, bv in “feat-abc”, dan naar test, tot binnenhalen in main.

Ik ga naar de pi, integreer daar alles van main in de lxde branch. Ik doe terloops ook nog een kleine correctie (die terug naar test/main moet).

Ik ga op de pc naar de map met de lxde, haal de wijzigingen af (pull), kan die openen en knippen/plakken naar het project dat in de ontwikkelomgeving open staat in dev directory.

Normaal zit in de dev directory ook de lxde branch, en kan je daar diff’s met test/main doen en zo.

Om een enkele tak lokaal toe te voegen, doe:

git remote set-branches –add origin [remote-branch]
git fetch origin [remote-branch]:[local-branch]

Doel: een “Developer” mogelijkheid geven om de main te updaten.

De leden van een project kunnen hun rol hebben gekregen doordat ze lid zijn va een “group”, en die kan dan niet apart ingesteld worden voor een subproject van die group, bv devcopyleft/clTools
Rollen zijn in stijgende volgorde : Guest - Reporter - Developer - Maintainer - Owner

Ga naar de hoofdpagina van de group, bv devcopyleft.
Daar bij “Manage”, zie je de “Group Members”.
Als je de nodige rechten hebt (oprichter van de group: “owner”) kan je in de kolom “Role” klikken op de rol en die veranderen, bv naar “Maintainer”.
Nu kan hij “push” naar “main” doen.

De Rapsberry Pi laten opstarten in een bepaalde toepassing

Er is een map waar bij het opstarten gekeken wordt welke programma’s te starten:/home/pi/.config/autostart

ps: In documentatie vind ik ook nog andere gelijkaardige mappen: /home/pi/.config/lxsession/LXDE-pi/autostart

Het kan dat de map ~/.config/autostart nog niet bestaat;

• op één pi bestond die niet en heb ik die gemaakt
• op de andere bestond die wel en bevatte die een bestand LXinput-setup.desktop, met toetsenbord/muisinstellingen

Een programma dat je in deze map zet wordt automatisch uitgevoerd.

Opstarten met een zelfgeschreven applicatie in gambas3
– Vanuit de gambas programmeeromgeving (Gambas3-IDE) kan je een programma compileren tot uitvoerbaar, met de optie om een link op de desktop te maken; doe dat.
– de link kan je dan naar de autostart map verplaatsen (of kopieren).

Access denied

git clone https://gitlab.com/devgroep/myprojectterminal.git
Cloning into ‘myprojectterminal’…
Username for ‘https://gitlab.com’: mijngebruiker
Password for ‘https://mijngebruiker@gitlab.com’:
remote: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password. See https://gitlab.com/help/topics/git/troubleshooting_git#error-on-git-fetch-http-basic-access-denied
fatal: Authentication failed for ‘https://gitlab.com/devgroep/myprojectterminal.git/’

Gebruik SSH keys
De site van gitlab legt dat goed uit;

https://docs.gitlab.com/ee/user/ssh.html

Kijk eerst of je al ssh sleutels hebt:

cd ~
cd .ssh/
Als je nog geen .ssh directory hebt, moet je checken of ssh geînstalleerd is, en/of genereer de ssh keys:

ssh-keygen -t ed25519 -C "mijngitlabaccountnaam"

Bij de vraag waar de key bewaren kan je normaal bevestigen:

Enter file in which to save the key (/home/user/.ssh/id_ed25519):

Als de .ssh map nog niet bestond, zal die nu gemaakt worden (geeft melding).

Nog wat bevestigen, en daarna vind je twee (nieuwe) bestanden, waarvan 1 de publieke sleutel is (die eindigt op .pub); en je kreeg ook wat randomart te zien…

The key’s randomart image is:

De inhoud van het pub bestand, inclusief opmerking, kopieren in de gitlab site bij je avatar, “edit profile, linkse kolom ssh keys”.. Add new key ..

De geldigheid kan je instellen als je wil.

Je ziet daarna dat de key is toegevoegd in je lijstje op https://gitlab.com/-/user_settings/ssh_keys

Nu vraagt git nog altijd mijn username en wachtwoord, maar nadien werkt bv het clonen wel.

Clean?
Een “cleane worktree” is je worktree na een commit/push of na een clone of pull.
Je ziet dat aan git status.

Dirty?
Vanaf je iets gewijzigd hebt, is het een “dirty worktree”, de toestand is “bezoedeld” door wijzigingen die nog nergens geregistreerd zijn.

Multiple?
Werken aan twee branches TEGELIJK.
(normaal schakel je om met git checkout branch1, hackhackhack, get stash, git checkout branch2, hackhackhack, git commit+push, git checkout branch1 ….)

Als je aan twee branches tegelijk wil werken kan je in een andere directory terug een clone doen van het project. Dan zit je met veel dubbele code, en moet je telkens beiden syncen. Je kan het Git zelf laten doen met git worktree, dan heb je minder ruimte nodig op de harde schijf, en verloopt het synchroon houden ook automatisch:
Bv: op een Raspberry Pi een “legacy” versie van software vergelijken met de huidige universele (die evolueert).

git worktree list
git worktree add MijnNieuweWerkboom *
en als je er mee klaar bent:
git worktree remove MijnNieuweWerkboom

Goede uitleg van het principe op https://tecadmin.net/git-worktrees-parallel-development-guide/
https://devdynamics.ai/blog/understanding-git-worktree-to-fast-track-software-development-process/

Eens die worktree gemaakt, zie je in je projectmap een map met de naam van de nieuwe worktree. En daarin staan terug dezelfde files als je al had in de directory erboven. Oei, dat was niet de bedoeling, die map hier in mijn projectcode te hebben.
(*) Belangrijk is om de directory op te geven waar die nieuwe worktree moet gezet worden bij git worktree add:

git worktree add ./../MijnNieuweWerkboom
of
git worktree add /home/username/directoryEtc

Terug verwijderen:
git worktree remove MijnNieuweWerkboom
git prune

git worktree add ./../MijnNieuweWerkboom
dan met
cd ..
cd MijnNieuweWerkboom
git status
git worktree list

Ik heb twee situaties gehad, de eerste was:
-1 In die directory zie ik een branch met de naam MijnNieuweWerkboom, terwijl ik die niet expliciet heb aangemaakt.

Normaal geef je als parameter een bestaande branch op (denk ik).

git worktree add ./../MijnNieuweWerkboom bestaandeBranch
(branch die ik daar wil om parrallel in te werken)
of
git worktree add /home/username/directoryEtc bestaandeBranch

-2 ik kreeg een foutmelding “invalid reference: bestaandeBranch”; misschien bestond die niet of had ik hem verkeerd geschreven.

-3: fatal: “.. is already checkout out at ..”
Dat is eigenlijk wel zo… Ik kon dit oplossen door eerst een andere branch aktief te maken:
git checkout otherbranch
git worktree add ../MijnNieuweWerkboom bestaandeBranch

.. preparing …
HEAD is now at .. (shows comment of commit)

Bij geval 1: In Gambas is de naam van de map ook de naam van het project, dus dat is nu plots ook veranderd.

Hmm, nog niet goed? Je kan bij het maken van een worktree (blijkbaar/soms) ook de naam van de nieuwe branch meegeven, verschillend van eender welke bestaande.

In mijn geval is het nu niet zo erg, je moet eventueel een nieuw configuratiebestand aanmaken, of het bestaande kopieren. Hierdoor kan je ze ook uit elkaar houden (bv voor de executable; handig dat de naam anders is).

---

Stash
git stash kan heel interessant zijn: je bewaart alleen je huidige veranderingen.

VRAAG: Dus als je twee gelijkaardige projecten hebt die enkel een beetje verschillen, maar die verschillen moeten blijven bestaan, dan kan je met stash je nieuwe werk bewaren (dat dan niet over die specifieke verschillen mag gaan), en die “toepassen” op eender welke andere branch, of je eigen branch als je dat nog niet gedaan had en toch was uitgecheckt.

hackhackhack
git stash wijzigingen op de LIFO
git stash show
git stash apply —-> this you can do on another commit; how?
git stash drop (laatste verwijderen)
git stash pop = apply + drop
git stash list
git stash clear (leegmaken)

git stash pop, ofwel git pop 0 (voor de laatste) git pop 1=voorlaatste enz. past de laatste stash to op de huidige worktree, en gooit hem daarna weg.

om “een stash” te verwijderen uit de “git stash list” doe je git stash drop i

Nu nog uitzoeken hoe ik een stash toepas op .. bv een ander worktree?

---

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – branch zoeken/datum – stash – git worktree – GitLab vb – SourceForge vb – git en gambas)

Eenvoudige merges, samenvoegen van iets dat verder voorop is en eenvoudig toegevoegd wordt aan een achtergebleven tak, is gemakkelijk te begrijpen, maar soms is het ingewikkelder.

git merge [-n] [–stat] [–no-commit] [–squash] [–[no-]edit]
[–no-verify] [-s ] [-X ] [-S[]]
[–[no-]allow-unrelated-histories]
[–[no-]rerere-autoupdate] [-m ] [-F ]
[–into-name ] […​]
git merge (–continue | –abort | –quit)

merge strategiën
De verschillende merge “strategies” zijn recursive, resolve, octopus, ours, subtree

Je kan zelf de merge strategy opgeven met een parameter:
(ook bij git pull trouwens)

git merge -s recursive tak1 tak2

git merge -s resolve tak1 tak2

git merge -s octopus tak1 tak2 tak3 .. takn

git merge -s ours tak1 tak2 .. takn

git merge -s subtree takA takB

Type van strategie

– Expliciet
Dit is de standaard merge methode. Het betekent dat er een nieuwe “merge commit” gemaakt wordt. Dit toont waar de merge werd gedaan in de merge geschiedenis, en dat is niet altijd gewenst (omdat het de aandacht afleidt, ruis dus). Als je deze details niet in je merge history wil, zal je misschien explicit merge vermijden.

– Impliciet
Impliciete merge via rebase of fast-forward merge

– Squash
Squash on merge, meestal zonder expliciete merge

Recursive merge strategy options

ours, theirs, patience, diff-algorithim, ignore, renormalize (no-normalize, no-renames), find-renames=n, subtree

Er zijn veel mogelijkheden, en hoe moet je kiezen wat te gebruiken alvorens je ze doorgrondt?

Een merge van twee branches (dev-hq en roadie) gedaan die verkeerd afloopt, bv omdat de versies meer verschilden dan je dacht (op beide was een stukje ontwikkeling gedaan ipv op één van beiden)? Je kan correcties gaan doen in de broncode, die door git voorzien is van merktekens als

< <<<< HEAD
======
>>>>>>> roadie

.. met daartussen brokken tekst van de verschillende versies.
Soms is het duidelijk, een klein verschil kan een eenvoudige correctie zijn, of een uitbreiding van een string of een commentaar. Dan kan je die onmiddellijk verbeteren met een .txt editor (zelfs buiten de normale programmeeromgeving).

Maar als de verschillen te groot zijn en/of je er niet aanuit kan, wil je misschien de “merge” operatie herstellen naar de toestand voordien.

Zolang je het conflict niet opgelost hebt, en niets kon pushen, niet gecomit hebt, kan je nog altijd terug met :

git merge --abort

Je kan info krijgen van git:

git reflog

Als je terug wil gaan naar de laatste gemeenschappelijke toestand, kan je die vinden met:

$ git merge-base dev-hq roadie
806f8ac3c61b1e55cdd5b53a0205b51d1d31387a

Dan kan je terug naar die toestand met

git reset 806f8ac3c61b1e55cdd5b53a0205b51d1d31387a

Unstaged changes after reset:
M .src/FConfigure.class
M .src/FConfigure.form

Om hem online te krijgen volstaat een gewone git push niet:

git push
To gitlab.com:stockpi/stockpiapp.git
! [rejected] dev-hq -> dev-hq (non-fast-forward)
error: failed to push some refs to ‘gitlab.com:stockpi/stockpiapp.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.

git push --force

git push –force
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: To create a merge request for dev-hq, visit:
remote: https://gitlab.com/stockpi/stockpiapp/-/merge_requests/new?merge_request%5Bsource_branch%5D=dev-hq
remote:
To gitlab.com:stockpi/stockpiapp.git
+ 8a060eb…806f8ac dev-hq -> dev-hq (forced update)

(zie bv https://www.atlassian.com/git/tutorials/undoing-changes/git-reset)
Julia Evans: “git rebase: what can go wrong?”

De pixels kunnen gestuurd worden met waarden van 0-255 per RGB kleur.

Met als extreme waarden voor Rood, Groen, Blauw:

Rood is (255,0,0)
Groen is (0,255,0)
Blauw is (0,0,255)
Geel is (255,255,0)
Oranje is (255,165,0)

Maar ook tussenwaarden geven mooie resultaten..

Zacht geel (60,40,0), minder fel
Flauw blauw ( 0,50,0), geschikt om te laten zien dat er stroom is maar zonder veel licht te geven.
Fuchsia (150,20,20)

enz..

Ja, je kan in 1 sql-statement een opvraging van verschillende databanken combineren (als je er toegang toe hebt met je account).

SELECT db1.table1.*, db2.table2.name FROM db1.table1, db2.table2 WHERE db2.table2.id=db1.table1.external_id

Je kan verschillende rechten hebben op de databases; bv op de ene tabel lees-wijzig-invoeg rechten, en op de andere alleen leesrechten.

Toepassing: database user planktonalfheim heeft enkel leesrecht op Alfheim2.application om de naam op te zoeken:

REVOKE ALL PRIVILEGES ON `Alfheim2`.* FROM 'planktonalfheim'@'localhost'; GRANT SELECT ON `Alfheim2`.* TO 'planktonalfheim'@'localhost';
REVOKE ALL PRIVILEGES ON `plankton`.* FROM 'planktonalfheim'@'localhost'; GRANT SELECT, INSERT, UPDATE, DELETE ON `plankton`.* TO 'planktonalfheim'@'localhost';

MariaDbServer
* Alfheim2

• application
  – id
  – name

* plankton

• issue
  – id
  – description
  – isactive
  – application_id

SELECT plankton.issue.*, Alfheim2.application.name FROM plankton.issue, Alfheim2.application WHERE plankton.issue.isactive=1 AND Alfheim2.application.id=plankton.issue.application_id

Database versioning. Brainstorm.

Ontwerp
Ik maak een applicatie (bv in Gambas3), en gebruik een mariadb databank om de gegevens op te slaan.
Ik exporteer de structuur en bewaar die mee in de broncode om dat databank terug op te kunnen bouwen.
De vorige wordt overschreven, alleen de huidige, bij de software passende versie databank.sql wordt hier bewaard. Door het versiebeheersysteem (Git), kan je teruggaan naar oudere software versies, en dan heb je daar ook altijd de bijpassende databank struktuur bij.

Verandering
Als er een verandering gebeurt aan de code en aan de “database structure”, moet ik ergens kunnen bijhouden welke versie van de database struktuur dit is (zeker als mogelijk verschillende applicaties of versies van software gebruikt worden om die aan te spreken).

Een logische plaats zou zijn: in de database zelf.

De wijziging aan de database moet kunnen gedetecteerd worden door de software; en als maar 1 software die databank gebruikt, zou de software die ook (automatisch) kunnen aanpassen/opwaarderen, of de juiste aanpassing kunnen suggereren.
Upgrade/Downgrade: als er een upgrade script is, ook een downgrade script voor ingeval onverwachte problemen (in productie).

Het zou goed zijn als de toepassing de databank struktuur checkt bij het opstarten, dan kan er geen te oude code draaien met een niet meer kloppende nieuwere versie van de databank.

De software moet dus ook weten voor welke versie van databank ze gemaakt is; bv met een constante gedefinieerd in Main “dBVersion = 10”.

Als er een “library” gebruikt wordt om de database te benaderen kan dat daarin.

Vorm
Hoe gedetailleerd moet de database struktuur versienummering zijn?
bv:
Db is aangemaakt, is versie 1, Db v1
Db is aangepast, extra tabel, Db v 2
Db heeft extra index gekregen, Db v2.1
Nog een extra index gekregen, Db v2.2
Extra velden in tabel, Db v 3.0
Extra velden krijgen index, Db v 3.1
Tabel bijgemaakt, Db v 4.0
Velden bijgemaakt daarin, Db v 5.0
Nog een tabel extra Db v6.0

De hoofdversie vereist overeenkomstige wijziging aan de code die de data gebruikt.
Een minor versienummer levert bv een praktische versnelling op, maar geen code wijziging?

Waarschuwing
– major versienummer verschil: waarschuwing en afsluiten/readonly (?).
– minor versienummer verschil: waarschuwing en verderwerken.

Bij major aanpassing:
– telkens de database structuur bij de broncode, dan kan in principe vanaf die struktuur vertrokken worden bij nieuwe installatie van het geheel (dus ook nieuwe databank).
– de code om de database op deze stand te brengen vanuit de vorige toestand.
Dus bij de developer moet de database-wijziging gebeuren met code, dezelfde die mee geleverd wordt als upgrade code voor de gebruiker. Dat zal niet altijd kunnen, als er dingen uitgeprobeerd worden bij development; maar uiteindelijk moet de developer dan toch de vorige volle versie terugzetten en een upgrade script maken tot de gewenste toestand.

Bij minor aanpassing:
– telkens de database structuur bij de broncode, blijft.
– ook deze aanpassing als code meeleveren.

History?
– in database een history bijhouden van in gebruik geweeste versienummers, met datum, updaternaam enz.

Best eens een test maken om dat uit te proberen…

MIT killed the cat

Er is door MIT geen versie meer gemaakt voor Linux van de recentste Scratch programmeeromgeving (vanaf Scratch 3.0).

De community spreekt nu over Scratux.

https://snapcraft.io/scratux

https://scratch.mit.edu/discuss/topic/326943/

NB: Op Raspberry Pi OS blijkt Scratch 3 wel beschikbaar.

mcedit
Met de Midnight Commander Editor mcedit kan je redelijk comfortabel shell scripts en configuratiebestanden aanpassen op de commandolijn zonder speciale shortcuts te moeten leren.
Shell scripts en andere broncode teksten worden meestal herkend, en krijgen een kleurmarkering volgens betekenis: commando’s, sleutelwoorden, commentaar enz.
Helaas zijn die kleuren niet altijd even goed zichtbaar ten opzichte van de achtergrondkleur bv groen tov blauw.

Syntax highlighting snel uitschakelen: Ctrl-s

Terug ctrl-s om weer in te schakelen.

Keuze
Om de kleuren aan te passen moet je in het “hoofdprogramma” zijn, Midnight Commander zelf: mc.
In het menu Options, Appearance kan je kiezen uit een aantal kleur-instellingen, die een niet altijd veelzeggende naam hebben. Ze worden “skin” genoemd, je moet op de spatiebalk drukken om het menu te openen:

default
(is standaard met blauwe achtergrond)

mc46
is ook blauw en heeft hetzelfde leesbaarheidsprobleem met groen

Enkele donkere werken misschien beter:

dark
gotar

heeft een zachte zwarte achtergrond:

modarin256

of een zachte grijze achtergrond:

gray-green-purple256

Aanpassen

Opstarten met aangepaste kleuren:
mcedit -C "editnormal=lightgray,black:editbold=yellow,black:editmarked=black,cyan"

De instellingen worden bewaard (en kunnen aangepast worden) in:
~/.config/mc/ini

Standaard staat er:

[Colors]
base_color=
xterm-256color=
color_terminals=

Vul bv aan met:

[Colors]
base_color=editnormal=lightgray,black:editbold=yellow,black:editmarked=black,cyan

Serial

Een Arduino bord heeft een programma dat (-bv om het te debuggen-) feedback geeft met print:

In de setup:
Serial.begin();

Je moet ook de snelheid opgeven, dus bv:
void setup() {
Serial.begin(9600);
}

In de code-loop:
Serial.println(someValue);

Bv in een loop:

void loop() {
Serial.println("Hello from Arduino..");
delay(1000);
}

De developer kan in de IDE de feedback zien met de tool “serial monitor”.

Losgekoppeld

Maar ook eens het programma loopt en de Arduino niet meer aan de programmeeromgeving hangt, kan je die seriële communicatie opvangen. Hang de usb-kabel aan een usb-poort van een Linux computer (Raspberry Pi, …).

1. Rechtstreeks vanuit het systeem/commandolijn
Om de hardware te benaderen moeten we root rechten hebben, ofwel telkens met sudo, ofwel:

su root

****

Werp een blik op de usb poorten:

lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 001 Device 002: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 001 Device 004: ID 2341:0043 Arduino SA Uno R3 (CDC ACM)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

tty

Seriëel in de Linux (unix) wereld is “tty”; en er zijn heel wat seriële apparaten mogelijk:

ls /dev/tty*

/dev/tty    /dev/tty20  /dev/tty33  /dev/tty46  /dev/tty59    /dev/ttyS12  /dev/ttyS25
/dev/tty0   /dev/tty21  /dev/tty34  /dev/tty47  /dev/tty6     /dev/ttyS13  /dev/ttyS26
....
/dev/tty15  /dev/tty28  /dev/tty40  /dev/tty53  /dev/tty9     /dev/ttyS2   /dev/ttyS4
/dev/tty16  /dev/tty29  /dev/tty41  /dev/tty54  /dev/ttyACM0  /dev/ttyS20  /dev/ttyS5
/dev/tty17  /dev/tty3   /dev/tty42  /dev/tty55  /dev/ttyS0    /dev/ttyS21  /dev/ttyS6
...
/dev/tty2   /dev/tty32  /dev/tty45  /dev/tty58  /dev/ttyS11   /dev/ttyS24  /dev/ttyS9

stty

Het commando dat de afkorting is van “Set Teletype”:

stty – change and print terminal line settings

Gebruik:
stty [-F APPARAAT | --file=APPARAAT] [INSTELLING...]

Wat?
stty -F

-F, –file=APPARAAT te gebruiken apparaat in plaats van standaardinvoer

Speciale instellingen:
speed de snelheid van de terminal tonen

Dus:
stty -F /dev/ttyACM0 speed

9600

(vreemd ik zou verwachten 115200 ..)
Eens proberen of ik hem kan verzetten:

stty -F /dev/ttyACM0 speed 115200

9600

Terug opvragen:

stty -F /dev/ttyACM0 speed

115200

Lees nu uit:
cat /dev/ttyACM0

SCD30 Raw Data

Carbon Dioxide Concentration is: 930.56 ppm

SCD30 Raw Data

Carbon Dioxide Concentration is: 930.51 ppm

Carbon Dioxide Concentration is: 929.86 ppm

….

Dit is dezelfde uitvoer die je krijgt in de IDE.
Je kan de Arduino aan eender welke bereikbare* Linux-bak hangen en vanop afstand met ssh inloggen en uitlezen, naar een logfile laten sturen, enz…

* bekend ip-adres

2. Serieële communicatie ontvangen met software
Vanuit eigen geschreven software in python of gambas3 kan je de serieële poort uitlezen.

2.1 Python:
Grofweg gezegd: gebruik import serial, creeer een object met eigenschappen in parameters, en maak een lus met serialobject.readline()

2.2 Gambas: gebruik SerialPort, creëer een object, zet eigenschappen, maak methode _Read(), gebruik een lus of Timer om uit te lezen.

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – stash – GitLab vb – SourceForge vb – git en gambas)

Undo
Wijzigingen niet bewaren (die niet toegevoegd waren – ‘not staged’) en terugkeren naar de laatste goede toestand van de bestanden in je directory:

– git reset --hard
Alle wijzigingen weggooien en terug beginnen met de vorige toestand van je ontwikkeltak.

– git checkout -- vuilbestand
Eén bestand terugdraaien naar de laatste normale toestand van voor je (klad)werk.
Een typisch voorbeeld is een .settings bestand dat kan reageren op het starten van een programma; bv omdat het een teller bevat, of de laatste toestand van schermen of geopende documenten bijhoudt of zo.

– git stash
Dit laat je toe de wijzigingen niet op te nemen in je programmeervoortgang, maar toch ook niet helemaal definitief weg te gooien; je zet ze opzij om voort te kunnen met je normale ontwikkeling.
Daarbij hoort nog:
git stash list : lijst van stash-items in tijdelijke editor (q=quit).
git stash show : diff
git stash apply : toepassen van deze stash op huidig werk.
git stash pop: toepassen van deze stash op huidig werk en uit stash halen.

Zie ook stash