Steeph's Web Site

Go To Navigation
Show/Hide Navigation

Entries tagged 'cat:Code'

SBWG 0.12.8

I've recently published a new version of SBWG, my web site generating bash script. The time that I'm able to allocate to working on SBWG fluctuated a lot in the last year and when I do work on it, I often just feel like doing one type of thing. So, when that is starting a new feature, all the other types of tasks can take on a pile that takes months to resolve. But eventually I managed to test and stabilise the features that I've added and changed, edited the README file and tried out the new version with real web sites. Well, testing could be more professionel, but it's okay for a hobby project, I think.

It's been well over a year since I wrote a blog entry about what's new in SBWG. This entry goes through the main new things since version 0.11.1.

A big new thing, at least from the view of the author/me, is that certain options where that makes sense now support multiple arguments. For example if you've edited three entries and want to re-generate just those three, you don't have to run the script three times but rather define the entries like this: sbwg -e ENTRYNAME_1 ENTRYNAME_2 ENTRYNAME_3. The same goes for pages, tagpages, entry attachments and galleries. This doesn't just make it easier and quicker to generate just some changed pieces of content. It also allows the usage of shell globbing (like *, ? and […]) and brace expansion ({…}). For example you can now regenerate all entries that are stored in one subdirectory or all entries whose names start with a vertain string of characters. Another practicle use case is to add external entries and/or to the site that are not stored in the respective directories in the web site's input directory. Using option -E/-P on the contents of an entire directory creates HTML files in the web site's output directory that look like any other of the web site's pages, but without integrating them in the structure of categories and other tags.

There is now a way to create a custom menu in the navigation bar without writing any code in the settings file of a web site. By using the new 'menu:' tag type in the header of a page or entry source file, the page or entry will get added to the menu. This allows for a list of pages you want to link to from the site's navbar, or a nested tree of interesting blog entries. The tag can be used similarly to the 'topic:' tag with the main difference that it doesn't add the entry or page to a list of entries with that topic, but rather directly in the navigation bar. In the default style set that is a drop down menu like the list of categories, authors, languages and topics. But it is just an unordered list, so it can be styled like any web site menu.

The default style set has changed a bit over the year. It basically looks the same but it's a bit cleaner now and is split into more file more logically. It will become even cleaner in the future though. It now also makes use of the new possibility to present the list of categories in the navigation bar in the form of a tag cloud. Audio attachments are better to look at now, especially when there are several audio files attached to an entry. Image attachments are can now be previewed in a modal without loading the (large) original file and without leaving the page. This almost gallery-like display is about as far as I'd like to go without starting to use JavaScript in the default styleset. Some parts of a web site generated with SBWG are now collapsible/expandable. The parts with this new feature are: entry attachments, entire entries on tagpages, entire entries on their own pages, the custom menu, the category list, topic list, language list and author list in the navbar and the entire navbar. By default all of those things are extanded upon page lead and collapsible by clicking/tapping on their titles. But you can add a setting in your settings file for each of those types of things to be collapsed upon page load and expandable by cliking/tapping on them.

Another thing that behaves similarly is content warnings. Hiding the content of an entry, or parts of it, could always be done by hand, e.g. by adding a <details> and <summary> tag pair to the body of the entry. But it is now easily possible by adding a warn: tag to the header of an entry. For example adding warn:This entry contains spoilers. to an entry header results in the entire content being hidden behind a collapsed <details> tag. Initially visible is only the summary "This entry contains spoilers. (click to open)". The default style set makes this warning line very visible but dunking it into a strong red. If the entry has attachments, those will be collapsed and their title marked in red, too. Both the entry content and its attachments will be collapsed by default if the entry has a warn: tag, independently of what your settings for those parts is in the settins file.

New special tagpages: If there are entries that have a language tag and others don't have one, 'nolang.html' will be created that lists all entries that don't have a language tags. Similarly, if at least one entry on the blog has an author tag, but other entries don't, 'noauthor.html' is created and linked to from the navigation bar.

RSS feeds are now created for every tagpage. That means visitors can now subscribe to individual topics or categories or authors or languages. It also means a longer generation time for a complete regeneration process. But permanent caching reduces that to an acceptable amount. Other feed formats are still not created because I reckon that writing those will be particularly fun and satisfying. So I want to get to that when more of the less interesting todo bullet points are done.

Many small changes make web sites with different structures than mine cleaner. Empty directories or menu entries aren't created. There are new hooks for the various different new functions and loops which a user might want to hook into. Various changes around the default language being used for RSS feeds and HTML documents in order to abide by the standards. Many bugs around all sorts of things have been fixed. The logging option works pretty reliable now. It may still be completely removed one day because it's a large chunk in the code, makes the script slower when enabled and can now be entirely replaced by redirecting output from the script on the shell level. The new flags 'hideinfeeds', 'noshow', 'nogal', 'noatts' and 'noheader' control how and where entries are presented and which parts are visible. See the README for descriptions of those flags.

Reading these update blog posts shouldn't be seen as a replacement for reading the CHANGELOG file. If you have a SBWG web site and consider updating SBWG, at least check the CHANGELOG for lines marked with ! since your current version. That makes it much much less likely that you miss something that you should change upon updating SBWG. I mean, I don't think anybody except me uses any version of SBWG. But I've always approached this project working as if it would be used by others in order to produce something that is practically usable without reading and understanding the codebase first.

The list of things that I'd like to do with SBWG is still long and includes heavy changes on how content is placed in the website's input directory. I reckon that it would take me something like 10 - 16 years to get there is I would continue advancing through the todo list at the pace at which I have in the last year. But if I would loose interest at any point along this path, I could feel okay for at least have gotton as far as testing and publishing version 0.12.8 because it's getting closer to looking how I want it to look in regards to the results it produces.

SBWG 0.11.1

I'm glad to have this version done and published. Even though it has new features compared to the last published version, I've used it enough to feel relatively comfortable saying it is also more stable and has fewer bugs than the last version. There are known bugs still left. But those aren't new.

Caching options and settings are slowly getting a bit elaborate, but also close to what I imagined them being able to do. There are new cachegroups and parts of entries can now be chosed as individual cachegroups, giving the user more control over what is cached and what caches are used. The lifetime of caches can now be set to make sure that no matter how the caching options are used, no outdated content, tags, attachments, etc. will stay on the web site for too long because cache files have been forgotten to be purges. The cache lifetime can be chosen from 1 second to unfinite. The directory used for persistant caches can now be chosen via command line option. I think the caching options are now in a state in which they can seriously be used reliably. Changes to existing cachegroups, like in previous versions, will probably not be made anymore. Just more cachegroups will be added.

The README file has grown a lot. Not only from new features and options. It's now also more complete. A lot of bugs have been fixed. And some general little code quality improvements took place. The stylesheets of the example web site have been improved a bit.

The messaging and logging system has been completely rewritten. It's not really an important part of the script and strictly doesn't matter for its functionality at all. But I decided to have a messaging system and a logging option that doesn't rely on shell redirects. So I did want to redo it properly. Different message types can now be redirected using file descriptors. The option parser has also been party re-written. It's approaching a state in which it's close to what I think personally a complete option parser for Bash should be like.

Alternate styles can now be defined in a web site's settings file. That way alternate style sheets will be offered to the web browser. If the browser supports alternate style sheets, the visitor can select from them to view the page in a different style. There is now an option to change the tagstyle, enabling a web site to have tags of the same type grouped for a more readable look of the entries' headers. Tags now show in parenthesis the number of entries that carry that tag. The number of file attachments is also displayed below entries.

The options for generating a single entry, page or gallery that is not located in the input directory/isn't actually part of the web site can now be used. They were very buggy or nonexistant before. Entries (and other items) with duplicate names are handled in defined ways now. Text files can now be used as file attachments to entries. But if the script determines one to look like a SBWG source file, it is omitted/not displayed/not linked to.

There are still big plans for future versions. Small and big features as well as a complete re-thinking of how the input directory is structured. Nicer looking web sites, more flexible command line options, more options for speeding up the script in cases where a complete website is updated/re-built. A pause like the one before this release will probably occur more often in the future.

SBWG 0.10.11

It's been two months since I published a new version of SBWG (and therefore since I worked enough on it to make me feel that an increase in the version number may be justified). I hardly get around to working on it, lately. But when I do, I try to make some solid small steps towards the improvements I wish do be done to SBWG.

So, now there is a new version (0.10.11) but I haven't published it yet because before I do I want to test it a bit more when I'm not as fucking tired as I am right now. Writing this entry could actually be considered part of the testing that I still want to do. But as I said, I'm fucking tired right now. So I'll continue this entry another time.

Edit 2022-09-12: I did some tests with fake content offline and feel confident that I fixed more than I broke in this version. I'll add it to the project page soon.

Two long procrastinate areas that have been overdue to get fixed for a while now are permanent caching and parallelisation. For permanent caching, the bugs that I found are fixed. Aggressive caching with option `--cache` (`-C`) works and certain groups can be selected (excluding others) for permanent caching. In my test this speeds up everyday web site re-generations by up to 100%. But it also means the user has to be aware of the cache files that persist after SBWG is done and will be used the next time. Changes to existing entries will not take effect without removing the relevant cache files. For parallelisation, the bugs that I found and that affect the generated HTML are fixed. I still consider parallel mode to be experimental. Sometimes messages on stdout are weird or cut off. But who uses very verbose mode and looks at every message anyway? Parallelisation is functional and usable is what I mean to say. In my test on a Core i5 with 4 cores (8 threads) it speeds up everyday web site re-generation by around 380% with default settings. It depends a lot on how much of web site generation is generating thumbnails and other image sizes of file attachments or gallery images. Those aren't sped up that much because the CPU already is the bottleneck for those. HTML file generation profits more from having more parallel threads than CPU cores (or threads) running.

SBWG 0.10.10

I decided to publish a new version of SBWG. I hardly got around to editing it in the last few months. So it doesn't really contain the new things that I had for a while intended for v0.10.10. But there were a few bugs that I wanted to have fixed in the latest published version. There still are known bugs. But now there are a few less.

Well, since it doesn't really contain anything new that's relevant, I didn't have to create this entry. But I did, so I'll use it to say I also fixed the RSS feed of draft0 and the menu link of steephlog on mobile. Bugs that I didn't know I had introduced in the last update and that were very happy that I didn't test things beforehand.

The things that did change since my last SBWG update just aren't that interesting. But I'll list some here, nevertheless: Entries can now have custom notes (using the 'note:' tag; Topic tagpages now also show the author names of entries; Srickied entries are now excluded from the RSS feed because they're just used as notices at the top of tagpages and don't belong context-less in the feed (there is a better solution planned); Error reporting inside of the script now includes information on the basis of which the clean-up routine can decide how to handle things differently for different errors and stuff; SBWG now locks directories; There is now a flag that hides attachments to an individual entry that are of a specific mime type, and, you could just read the CHANGELOG file instead of this if you really are interested in these little changes.

It'll probably continue to be slow in the foreseeable future. There are a lot of ideas in my head and several bugs in the code and probably vice versa. But time… not so much.

Edit: Oh, and another thing: I started to test updates and changes that I made to SBWG live on this web site because it's more fun if something breaks every other day. I'll pretend I don't mind.

PIN Changer

I had to change the default PINs of over 200 SIM cards once. And such a situation could arise again. So I've built a PIN changer in which I just have to insert the card, wait a few seconds and it's done.

The Card Slots

SIM cards in their natural form factor aren't as fiddly to handle as they are in the form factors most people know, which is Mini SIM, Micro SIM and Nano SIM. Classical SIM cards are the same size as other smart cards. I found a card slot with an end switch on eBay. I like it when I find industry grade parts for cheap on eBay as part of some remaining stock. Additionally I've used a slide-in mini SIM slot and another, separate end switch from my parts collection in case I to change the PINs of smaller cards.

The Baseband Processor

Other parts that I've used is an Arduino Nano sized Arduino Nano nearly-clone and an A6 modem module. There are many similar modem modules designed around different but similar ICs. Many of them are cheap and widely used for DIY IoT projects. So example code for the Arduino and other help can be easily found on the web. I don't know why I went with a module with an A6. But it works fine and there are an Arduino library for it as well as cheap modem modules with it available.

(tba:voltage supply)

The Controller

Yes, Arduino may be kind of the noob go-to board and could look up how to use microcontrollers on their own finally and even if I don't want to I could finally start to use ESP32s like everybody else. But I know Arduinos and by now I'm familiar with it and it works, so, whatever. Arduino Nano is kind of my go-to form factor now because they have integraded USB, are Uno compatible and small. Unless I need more or something very specific I use Arduino Nano almost-clones with USB-C port.

The Code

The code is a real mess. It had been a long time since I had written any even halfway serious C. It may have been the first time, actually. The sketch surely is very easily improved by somebody who knows what they are doing. I intended to improve it myself. But the project is currently abandoned and The code is doing what it should in a way I initially had in mind as the goal. But I'll leave the mess of the comments in for the case that somebody wants to make out what I was thinking.


// Funktionen umschreiben: Beim Empfangen wird erwartet: 1. der AT-Command zurück, 2. eine Antwort, 3. OK oder ein ERROR.
//                         Daher sollte abgefragt werden, bis entweder OK oder ERROR kam oder 20/50/9001(?) Abfragen lang weder OK noch ERROR an kam.
//                         Die Antwort in Variable speichern? Naja, String zurückgeben halt.
//                         Antworten, die mit "^" anfangen brauchen nicht gehandlet zu werden, da keine Kommandos, die mit AT^ beginnen gesendet werden.


#include  

SoftwareSerial A6MODULE(6,7);
int intled = 13; // Internal LED
int successled = 8; // Green LED
int failled = 9; // Red LED
int wrongpinled = 10; // Orange LED

boolean debug=true;

//String commands[5] = { "AT", "AT+CPINC2", "AT+CPIN?", "AT+CLCK=\"SC\",2", "AT+CPIN=\"3010\"" };
//int command = 0;

const byte maxmsglength = 32;
char received[maxmsglength];
boolean newData = false;
String response = "";

int i=0;

/*
To check/do:
1  AT: OK?
2  is PUK required - abort
3  are less than 3 PIN attempts left? - abort AT^CPINC=?
4  is PIN disabled
       5  enable it: 0000
6  is PIN enabled
       7  unlock
8  is card unlocked
       9  change PIN: 1996
              was PIN wrong - report and leave it
*/


void setup() {
  pinMode(intled, OUTPUT);
  pinMode(successled, OUTPUT);
  pinMode(failled, OUTPUT);
  pinMode(wrongpinled, OUTPUT);
  // All LEDs turn on at the beginning and stay on during the wait period at the beginning, then turn off before communication with the A6 module starts.
  digitalWrite(intled, HIGH);
  digitalWrite(successled, HIGH);
  digitalWrite(failled, HIGH);
  digitalWrite(wrongpinled, HIGH);
  Serial.begin(9600);
  delay(500);
  digitalWrite(intled, LOW);
  digitalWrite(successled, LOW);
  digitalWrite(failled, LOW);
  digitalWrite(wrongpinled, LOW);
  A6MODULE.begin(9600);
  delay(500);
  digitalWrite(intled, LOW);
}

void loop() {
  sendtoa6("AT");
  if(getfroma6("OK")) {
//    sendtoa6("AT+CPIN?");
//    if(getfroma6("+CPIN:SIM PUK")) { fail; }         // If the required password is PUK, abort.
//    sendtoa6("AT+CPIN?");
//    if(getfroma6("+CPIN:SIM PIN2")) { fail; }        // If the required password is PIN2, abort.
//    sendtoa6("AT+CPIN?");
//    if(getfroma6("+CPIN:SIM PUK2")) { fail; }        // If the required password is PUK2, abort.

// WAIT FOR SWITCH RELEASE FIRST
    sendtoa6("AT+CPIN?");
    getfroma6("+CPIN:SIM PIN");                      // The last non-empty response will be stored in the global response variable. Problem with this: If the A6 module sends an unsolicitated message before the response to the CPIN command, nothing gets done and the card needs to be re-inserted again.
    if(strcmp(response, "OK") == 0) {                // If already no PIN is required

//      sendtoa6("AT+CLCK=\"SC\",2"); // Ist PIN-Abfrage eingeschaltet? Oder ist es "SC"?
//      if(getfroma6(???)) { PIN-Abfrage einschalten mit 0000; }

      // ENABLE PIN HERE
      d("I don't know how to enable the PIN.");

    }
    if(response = "+CPIN:SIM PIN") {                 // If the required password is PIN, continue.
      sendtoa6("AT^CPINC=?");
      if(getfroma6("^CPINC: 3")) {                   // If not exactly 3 attempts are left, abort. (should be larger than or equal to 3, shouldn't it?)
        sendtoa6("AT+CPIN=\"0000\"");                // Freischalten mit 0000
        delay(50);
        if(!getfroma6("OK")) { fail; }               // If that was not the right password, abort.
        sendtoa6("AT+CPWD=\"SC\",\"0000\",\"1996\"");// PIN ändern
        delay(500);
        if(getfroma6("OK")) { Serial.println("Looking good."); }

//      sendtoa6("AT+CMGD=0,4"); // Should delete all SMS
//      if(getfroma6(???)) { ; }
        d("I don't know how to delete SMS.");

        sendtoa6("AT+CPIN?");
        if(getfroma6("+CPIN:READY")) {
          
          // TURN OFF A& MODULE FOR SAFE CARD REMOVAL

          digitalWrite(successled, HIGH);
        }
      } else {                                         // If not exactly 3 times left
        fail;
      }
      delay(1000);
    }
  }
}

void fail() {
  digitalWrite(failled, HIGH);               // Turn red fail LED on and ...
  d("Something failed! Ending programme.");
  while(1);                                  // ... don't do anything anymore.
}

void wrongpin() {
  digitalWrite(wrongpinled, HIGH);           // Turn yellow LED on and ...
  d("Wrong PIN! Ending programme.");
  while(1);                                  // ... don't do anything anymore.
}

//boolean getfroma6(char str[32], char str1[32], char str1[32], char str1[32], char str1[32], char str1[32]) { // Returns true if the passed (expected) message was received, false if anything else was received.
boolean getfroma6(char str[32]) { // Returns true if the passed (expected) message was received, false if anything else was received.
  boolean asexpected = false;
    for (i = 1; i < 9; ++i) {
    receivelinefroma6();
//    d("d1 "+response);

    if(received[0] == '\0') {                            // If the received message is empty
      continue;
    } else {
      response = received;
    }
    if(strstr(received, "ERROR") != NULL) {              // If the received message contains "ERROR"
      d("Received an error: "+response);
      fail;
    }
    if(received[0] == '+') {                             // If the received message starts with a "+" sign
      d("Reseived response: "+response);
    } else {
      if(strstr(received, "OK") != NULL) {               // If the received message is "OK"
        d("Received OK.");
        asexpected = true;                               // Also treat OK like the expected message. No unexpected OK should ever be sent from the A6 module. So this is fine. No, it is, really.
//        if(asexpected) { return true; }
      } else {
        if(strncmp(received,"AT",2) == 0) {              // If the received message starts with "AT"
          d("Received AT: "+response);
        } else {                                         // For any other received message
          d("Received: "+response);
        }
      }
    }
    newData = false;
    if(strstr(received, str) != NULL) {
      d("Received expected message: "+response);
      asexpected = true;
    }
  }
  if(asexpected) { return true; }
  return false;
}


//void handleresponse() {
//  response = received;
//  if(received[0] == '+') {
//    d("               Response: "+response);
//  } else {
//    if(strstr(received, "OK") != NULL) {
//      d("               It's okay.");
//    } else {
//      if(strncmp(received,"AT",2) == 0) {
//        d("               I've sent: "+response);
//      }
//    }
//  }
//  newData = false;
//}



void receivelinefroma6() {
  delay(80);
  static byte counter = 0;
  char rc;
  
  received[0] = '\0';

  while (A6MODULE.available() > 0 && newData == false) {
    rc = A6MODULE.read();

    if (rc != '\n') {
      received[counter] = rc;
      counter++;
      if (counter >= maxmsglength) {
          counter = maxmsglength - 1;
      }
    }
    else {
      received[counter] = '\0'; // terminate the string
      counter = 0;
      newData = true;
    }
  }
}

void sendtoa6(String command) {
//  Serial.println(command);
  A6MODULE.println(command);
  d("Sent: "+command);
}

void d(String line) {
  if (debug == true) { Serial.println(line); }
}

(tba:connections,assembly,photos?)