Archive

## Tag Cloud

3d account algorithms announcement architecture archives arduino artificial intelligence artix assembly async audio bash batch blog bookmarklet booting c sharp c++ challenge chrome os code codepen coding conundrums coding conundrums evolved command line compilers compiling compression css dailyprogrammer debugging demystification distributed computing documentation downtime electronics email embedded systems encryption es6 features event experiment external first impressions future game github github gist graphics hardware hardware meetup holiday holidays html html5 html5 canvas infrastructure interfaces internet io.js jabber javascript js bin labs learning library linux low level lua maintenance manjaro network networking node.js operating systems performance photos php pixelbot portable privacy programming problems project projects prolog protocol protocols pseudo 3d python reddit reference release releases resource review rust secrets security series list server software sorting source code control statistics storage svg technical terminal textures three thing game three.js tool tutorial tutorials twitter ubuntu university update updates upgrade version control virtual reality virtualisation visual web website windows windows 10 xmpp xslt

## Rendering LaTeX documents to PDF: Attempt #2

It was all going rather well, actually - until I discovered that pandoc doesn't support regular bibliographies / references. Upon discovering this, I ended up with a bit of problem. Thankfully, the answer lay in pdflatex - but getting to the point where I could use it without having it crash on me (which, by the way it can't accomplish properly - it gives an exit code of 0 when crashing! O.o) was not a trivial journey.

This blog post is a follow up to my first post on rendering LaTeX documents with pandoc, and is my attempt to document what I did to get it to work. To start with, I installed texlive properly. Here's how to do that on apt-based systems:

sudo apt install texlive-latex-extra --no-install-recommends

The no-install-recommends is useful here to avoid ~450MiB of useless documentation (in PDF form, apparently) being dumped to your hard drive. I've also got an arch-based system (it's actually Artix Linux, that I've blogged about) which I've done this on, so here's the install command for those kind of systems:

sudo pacman -S texlive-latexextra

Once that's installed, we can use it to render our LaTeX document to PDF. Upon discussing my issues with my Lecturer at University, I discovered that you actually have to run 3 commands in succession in order to render a single PDF. Here they are:

bibtex filename
pdflatex --output-directory=. filename.tex
pdflatex --output-directory=. filename.tex

The first one compiles the bibliography using BiBTeX. If it isn't installed already, you might need to search your distribution's repositories and install it. Next, we run the LaTeX file through pdflatex from TeXLive not once but twice - as it apparently needs to resolve the references on the first pass (why it can't do them all in once pass I have no idea :P).

It's also worth noting that the bibtex command doesn't like you to append the filename extension - it does it automatically, apparently.

That's about everything I've got on the process so far. If you've got anything else to add, please let me know in the comments below (I'm rather new to this whole LaTeX thing....)

## Rendering LaTeX documents to PDF on Linux (and maybe Windows too)

I'm starting to write another report for University, and unlike other reports, this one apparently has to be a rather specific format. To that end, I've got two choices, apparently: Use the provided Word / LibreOffice template, or use a LaTeX template instead. After the trouble and frustration I had with LibreOffice for my previous report, I've naturally decided that using the LaTeX template might be a good idea.

After downloading it, I ended up doing some research and troubleshooting to get it to render properly to a PDF. Now that I've figured it out, I thought I'd share it here for anyone else who ends up experiencing difficulties or is unsure on how it's done.

The way I'm going to be using it is with a tool called Pandoc. First, install it like so:

sudo apt install pandoc texlive-fonts-recommended

Adjust as necessary for your distribution - Windows users will need to read the download instructions. The texlive-font-recommended package is ~66MiB(!), but it contains a bunch of fonts that are needed when you're rendering LaTeX documents, apparently.

With the dependencies installed, here's the command to convert a LaTeX document to a PDF:

pandoc -s input.tex -o output.pdf

Replace index.tex with the path to your input file, and output.pdf with the desired path to the output file. I haven't figured out how to set the font to sans-serif yet, but I'll probably make another post about it when I do.

Found this helpful? Still having issues? Let me know below! I don't have analytics on here, so that's the only way I'll know if anyone reads this :-)

## Change the way you think: Languages and Compilers in Review

Change the way you think.

I haven't seen it used recently, but when I first arrived at Hull University to start my degree, that's the phrase I saw on a number of posters about the place. I've been thinking about it a lot over the course of my degree - and I've found that it has rung true more than one. My understanding of programming has been transformed 3 times that I can count, and before I get to the Languages and Compilers review that this post is supposed to be about, I'd like to talk a little bit about that first.

The first time my understanding transformed was when I arrived in my first year. Up until that point, I'd been entirely self-taught - learning languages such as _GML_ and later Javascript. All of a sudden, I was introduced to the concept of _Object-Oriented Programming_, and suddenly I understood that by representing things as classes and objects, it was possible to build larger programs without having them fall apart because they were a nightmare to maintain.

Then, when I was finishing up my year in industry, my understanding was transformed again. I realised the value of the experienced I'd had while I was out on my year in industry - and they have not only shown me mechanisms by which a project can be effectively managed, but they have also given me a bit more of an idea what I'd like to do when I finish my degree.

Finally, I think that in Languages and Compilers is the third time I've changed the way I think about programming. It's transformed my understanding of how programming languages are built, how their compilers and interpreters work, why things are they way they are. It's also shown me that there's no best programming language - there only the best one for the task at hand.

With this in hand, it gives me the tools I need to pick up and understand a new language much more easily than I could before, by comparing it's features to the ones that I already know about. I've found a totally new way of looking at programming languages: looking at them not on their own, but how their lexical style and paradigms compare to those employed by other languages.

If you're considering whether a degree in Computer Science is worth it, I'd say that if you're serious about programming for a living, then the answer is a resounding yes.

## Nasty Example SPL Programs

I've written a few example test programs to debug various edge cases whilst writing a compiler for my coursework at University, and I thought I've post them here to help others out. As this coursework is ongoing I'm not going to say anything else, but I hope that these help someone else out :-)

Anyone posting coursework compiler code here will have it deleted (but additional example SPL programs are welcome). In addition, I make no guarantees that these programs are even valid SPL that should compile.

### Nasty A

NastyA:
DECLARATIONS
a OF TYPE INTEGER;
CODE
WRITE(a);
WRITE(45, 'c', 5.68249)
ENDP NastyA.

### Nasty B

NastyB:

DECLARATIONS

i, toggle, step, limit OF TYPE INTEGER;

CODE

1 -> toggle;
1 -> step;
10 -> limit;
FOR i IS 1 BY step TO limit DO
IF toggle = 1 THEN
-1 -> step;
-1 -> toggle;
-10 -> limit
ENDIF;
WRITE(i);
NEWLINE;
WRITE(toggle);
NEWLINE;
WRITE(step);
NEWLINE;
NEWLINE
ENDFOR;
NEWLINE

ENDP NastyB.

### Nasty C

NastyC:

DECLARATIONS
a,b,c OF TYPE INTEGER;
d,e,f,g OF TYPE REAL;
CODE
5 + 8 -> a;
4.5 + 6.8 -> d;
WRITE(a);
NEWLINE;
WRITE(d);
NEWLINE;
WRITE((8 - 4));
NEWLINE
ENDP NastyC.

## Flexible Bison: Compiler Theory

One of the modules I've picked to do in my first semester of my third year at university is Lanuguages and their Compilers. Naturally, this entails building a compiler to compile a program that's written in a source language (spec provided, thankfully! :D) into plain old ANSI C.

The tools we're going to be using for this and the steps involved in actually compiling something into another language are somewhat complicated, and I'm having a bit of difficulty getting my head around the different steps a compiler goes through and how these steps relate to the tools we're going to be using. This blog post is my attempt to make sense of what I've learnt so far.

Firstly, let me introduce the tools I'll be using: GNU flex and GNU bison. Apparently they have a much shallower learning curve than other tools out there. At first, this doesn't appear to be the case - but the more I think about it the more I realise that this is true.

Flex, as far as I can tell, is a regular-expression based scanning tokeniser. In other words, it breaks down an input string into a series of tokens. It has a method that, when called, finds and returns the next token from the source string.

Bison uses tokenised output from flex to construct a parse tree. This parse tree is then optimised with redundant nodes removed, loops optimised, and other such tweaks. Finally, this optimised tree is then used to generate the output code.

With the cast introduced, I can get to the stages of a compiler:

1. Lexical Analysis - Tokenisation
2. Syntactical Analysis - Conversion of the token stream into a parse tree
3. Semantic Analysis - Correction of the tree - e.g. automatic type conversion
4. Intermediate Code Generation - Sometimes the compiler outputs sets of 3 values in a list of tuples. This was needed in older computers that couldn't hold all the steps of a compiler in memory at once! In my case, I'll be outputting the parse tree generated in step 3 I guess - but not to disk, as today we can have all the passes of the compiler in memory at the same time :D
5. Optimisation - Redundant parts of the parse tree are removed etc. - loops are focused in particular
6. Code Generation - The output code in the target language is generated here - whether that be in C (very common), Assembly, or another language.

This seems somewhat familiar. The Lexical Analysis phase seems to be rather similar to what flex is designed for, and the Semantic Analysis stage appears to what bison does. As for the other stages, I'm not really sure. I'm guessing that it'll become clear later as we build this compiler in stages - but I'm suspecting that we'll be writing them in plain C - unless I've missed something about bison :P

If you've made it this far, thanks for reading! If this feels somewhat disorganised - then it probably is - after all, this is mainly to get it all straight in my own head :P

## University: Begin!

Since I start my third year at university on Monday, I thought I'd make a quick post here about what you can expect to see on here in the future. If you're starting another (or your first!) year of university this year, I wish you good luck!

In the first semester, I've chosen a pair of modules about languages and their compilers and virtual reality. I thought the former sounded quite cool - I'm hoping that I'll end up understanding what goes on under the hood in the compilers that power the languages we use today. I haven't had much exposure to the latter - so I thought that it would be a good introduction to the subject to 'broaden my horizons', so to speak - that is to say I'm curious to investigate an area that I haven't touched before.

For the second semester, I've chosen a mobile development module and an advanced AI module. Personally I'm most excited about these two - The Prolog that I did (and posted about!) before was actually really rather fun and made sense in a strange sort of way, so I thought I'd try my hand at the next level. Mobile development is another area that I've been interested in experimenting with - I've been pondering writing an Android app for Pepperminty Wiki, my lightweight wiki engine that powers a personal project of mine.

With this in mind, you can expect to see a bunch of blog posts relating to these areas that I'll be exploring :D

## Writing code when you don't have the time

As you've probably noticed, posts around here have slowed down recently. There's a reason: I've been very busy doing a year in industry. Currently, my goal is to release one post a week. While my time has been rather fragmented and at times extremely limited, I've still been able to sit down for a little while here and there to write some blog posts and some code (If I can actually pull it off, I've got a seriously cool project I'm going to post about on here in the near-ish future!).

Due in part to the fact that I really don't want to exclusively write code at my industrial placement, I've been trying my hardest to keep programming and playing around with things in my free time. It's not as easy as you might think. Sometimes, the setup and teardown time eats all the time I allocated away so can't actually get anything done.

If this sounds a little bit like your time at the moment, fear not! I have developed a technique or two I wanted to share on here, just in case someone else finds it useful :-)

Planning what it is that you want to do is really important. You probably know this already, but it is especially so if you don't have a ton of time to throw at a project, because otherwise you can easily spend longer figuring out what you need to do next than actually doing it. I try to break my projects down into small, manageable bite-sized chunks that I can tackle one at a time. Only have 1/2 an hour at a time? Break it down into portions that will take you about 1/2 an hour complete. It might take a while, but breaking your project down can help it go a little bit faster.

Even with breaking my project down, I often find myself forgetting where I got to last time. To tackle this, I've discovered that leaving a comment in the file I was last editing explaining in a sentence or two what I need to do next helps me figure it out faster. It's also really useful that my editor (whichever one I'm using at the time) is configured to remember the files I had open last - letting me quickly pick up where I left off. Monodevelop, Visual Studio, and Atom do this automatically - if your editor doesn't, there's bound to be a setting or an extension that does it for you.

By planning what I need to do next, and leaving myself short comments explaining what I was about to do next, I can increase the amount of time I spend actually writing code instead of fumbling around working out what I wanted to do next. It's certainly not an ideal way to program, but with practice you can get quite proficient at it....

Found this helpful? Got any tips yourself? Comment down below!

## I've got some business cards!

I've been to several events of various natures now (like the Hardware Meetup), and at each one I've found that a 'business card' or two would be really handy to give to people so that they can remember the address of this website.

After fiddling with the design over about a week I (and Mythdael!) came up with the design you see above. Personally, I'm really pleased with them, so I decided to post here to show them off :-)

I'm finding that it's a rather good idea to promote and build your brand at these kind of events by showing people the cool things that you've created and learnt, and business cards seem to be just the thing that helps you do it.

## How to run a successful blog: My experiences so far

About 2 and a half years (and 207 posts!) ago today, I took the advice of Rob Miles and started this blog. I've learned a lot since I started from some wonderful people, and the quality of my posts on here has improved immensely. I've been meaning to write a post on what I've learnt about running this blog, but haven't gotten around to it until now :-)

The first, and most important, thing you can do is to post often. By posting often you keep people coming back to read more. If you leave it too long between posts, people may forget about your blog and may not come back.

Of course, while having regular content is good, having a posting schedule is considered by some to be even better. While I'm not particularly good at this yet, if you do manage to achieve it you can ensure that people know when they can come back and expect another post.

It's also important that you post about something you find interesting. Doing so improves the quality of the post, and it makes for a much more interesting read. If you're passionate about what you're writing about, people will generally come back for more.

Next, blogging is something that you have to persevere with. You certainly won't acquire readers overnight. It's worth bearing in mind that most of your readers will be silent - only a very small proportion of readers will actually leave a comment, no matter how easy you make the process (I hardly ever get comments).

Also, don't set out with the goal of getting $x$ number of regular readers, or earning $y$ amount of money. They are bad motivators to have, and you will surely be disappointed. Rather, you should set out to just write about something you love, without expecting anyone to read what you've written. Then you'll be pleasantly surprised :D

That's all I can think of right now. There are surely other things that I haven't mentioned. If you have any tips you've learnt from running a blog of your own, post about them in the comments :D

## My robot works!

I went to the hardware meetup again today. For the last 2 times I've either managed to forget or I've been on holiday (probably both...), but I remembered this time around and I decided to go. I'm glad I did, because, with Rob's help I fixed my robot! It is now trundling around on the floor quite happily :D

The problem was that I assumed that the digital pin numbers on the wemos D1 R2 were the same as the GPIO pin numbers, which isn't the case apparently. Here's a table:

Digital GPIO
D0 GPIO 16
D1 GPIO 5
D2 GPIO 4
D3 GPIO 0
D4 GPIO 2
D5 GPIO 14
D6 GPIO 12
D7 GPIO 13
D8 GPIO 15

(Table from wemos.cc)

Very odd numbering. It's rather frustrating actually! Anyway, there seemed to be quite a lot more people there this time as compared to last time - it looks like the idea is taking off, which I'm very glad about :-)

If you're in the Hull area and interested in hardware, you should seriously consider coming along. There's a page on meetup.com that contains the details of the next meetup, but the general rule of thumb is that it happens at C4DI every first and third Thursday of every month at 6pm - 8pm.

Before I forget, I'm going to end this post off by posting the modified version of Rob's hull pixelbot dance code that works on the Wemos:

(Git Repo, Raw)

Art by Mythdael