Fetch GitHub Pull Requests Locally

It’s by no means a secret thing and Google will be the first to tell you, but by the off chance that someone hasn’t thought about it, here’s just the command how to do it.

git fetch origin pull/<id>/head:<branch>

<id> refers to the pull request id on GitHub
<branch> refers to a custom branch name of your choosing
Note: You can’t push back changes, but you can push them to your repository and create a new pull request.

Since we’re merging pull requests manually at SFML, it’s a command I’m using very frequently.

Visual Studio Tip: Save Layouts

When working a lot with Visual Studio, you’ll run into the issue of managing your windows properly. You may spend quite some time figuring out the perfect layout, only to have Visual Studio randomly move a window around again, when you have to restart Visual Studio. Or you keep rearranging your windows depending on what you’re currently working on. Either way, you spend too much time fighting the IDE, instead of getting work done. Continue Reading “Visual Studio Tip: Save Layouts”

Generate a DEF file from a DLL

Last night I spend multiple hours trying to get a non-broken CSFML build ready, which requires to have import libraries for MSVC and GCC that both depend on the same DLL. This works because the import library only points to the symbols that are in the DLL, thus acts as sort of instruction how to use the DLL.

Continue Reading “Generate a DEF file from a DLL”

Rule of Thumb – Linking Order

Those newer to programming in C++ often fail to understand that compilers like GCC or Clang require a specific link order for the libraries in use or they don’t know what order to pick. Working on SFML and helping out in its community, I’ve had the pleasure to help people fix their linker errors many times and every now and then I’d explain a short rule of thumb one can keep in mind when specifying libraries to be linked. As such I wanted to share it here with you too.

Continue Reading “Rule of Thumb – Linking Order”

When VLC Doesn’t Update Anymore

Most of us probably ran into a bug in some application at one point. Sometimes it’s not very obvious, e.g. a random crash, while other times you may know that, if you for example perform certain five steps it will crash. But what do you do when you find an issue? Do you just avoid the crashing steps? Do you restart the app and keep working? Or do you put in some time and try and report the issue to the developer?

As a developer myself, detailed bug reports and active involvement in the bug report have been among the most valuable things in fixing bugs. As such, I can only highly recommend to send in bug reports whenever possible! Here is just some bug hunting story from last weeks.

Last week I opened the great video player VLC to playback some Opus audio file. Shortly after opening the application, it reported that there was a software update. I vaguely remembered that it already previously mentioned that, so I was a bit confused why I didn’t update then. Of course I accepted to download the new version and after 22% through the download process, VLC simply crashed. Aha! That’s why I didn’t update VLC last time. And indeed whenever you try to update VLC it would simply crash.

VLC Crash

I remembered back when ShareX didn’t update when you clicked on the auto-update message and also remembered that they put up a notice on their website to manually update it. Certainly a broken update function in a quite popular media player would have been reported by now and thus I checked the website. To my surprise however there was no notice and searching a bit further I couldn’t find a report either. So I took things to the VideoLAN IRC channel and quickly found some active user.

After some digging we found the debug nightly builds. With that in hand, I thought it would be very easy to get a stack trace of the crash, but because this was a nightly build, the update feature points to a test server and while it actually triggered an update to be run, the build to update to wasn’t available anymore and thus nothing happened.

My next idea was to simply spoof the update server and change the update information. Having Python installed on my system I could just run python -m http.server 80 and it would launch a web server that served the files in the working directory. Then I added the update server to my hosts file, placed the update text file in the web server’s directory and … VLC’s update feature now simply threw an error. Luckily the debug build also output a lot of useful information in the console, so I saw that the update tests a signature file. This security feature prevents exactly this kind of “attack” where the DNS is spoofed and the fake server serves a malicious update. Having a file with a PGP signature ensures that only the ones with the private key can provide binaries with matching signatures.

So the new plan was to simply take the update file for the latest release version and its signature file. Finally, VLC crashed and I could get the stack trace. With an impressive list of 1637 entries, it became clear that the crash must be some sort of infinite recursion, which fills up the stack and finally leads to the crash. Since the problem seems to occur around lots of Qt functions, it may end up being less of an VLC issue and more one of Qt. A report was filed and now the waiting game beings.

Critique

In my books having a broken update function seems quite critical, as your users won’t get any security updates anymore, but need to go to the website and manually update VLC and many will probably just disable auto-update to not receive that message anymore. As such the reaction so far have been too low for my liking and I’m surprised that nobody else has experienced this issue. Then again VLC is an open source software maintained by developers in their free time, so it’s not a surprise that things take a bit longer.

The fact that the update feature doesn’t work due to outdated files in the nightly/development builds is a bit concerning. If it can’t be tested easily, then it simply won’t be tested at all and bugs like the one mentioned won’t be found during development.

VLC’s automatic reporting system doesn’t work (anymore). The FTP server the reports gets send to, doesn’t seem to exist anymore. In the consumer market direct reports to the team like mine are quite rare, so an automatic crash report system should work, so you actually see in case VLC suddenly keeps crashing all around the world.

Summary

As a software user, report bugs whenever you can and include as much information as possible!

As a software developer, make sure your features can be tested and that debug builds/symbols are available to get more detailed information.

I wanted to write some more on how to report bugs, but this post has already turned into a longer one, so I’ll reserve that for a dedicated entry.

NightlyBuilds have been updated!

Looking at the last news entry on the NightlyBuilds website, it seems like it has nearly been two years since I last update the Nightly Builds.

https://nightlybuilds.ch/

Nightly Builds

One of the reasons I didn’t bother as much to keep them updated was, because we at SFML now have setup a Continues Integration system which allows anyone to download the latest builds for various compilers. Additionally my system still isn’t very automated, so I always have to spend quite a bit of time to get everything ready, especially having to update all the compilers. But I’ve made things a bit easier by rewriting my build scripts, so an update to a new compiler version is a lot easier.

I’ve removed all the older compiler versions (VS 2010, 2012, 2014, 2015 RC, MinGW < 6) and now have just four compilers listed:

  • MinGW Builds Posix Dwarf 710r0 32-bit
  • MinGW Builds Posix SEH 710r0 64-bit
  • Visual Studio 2017 32-bit
  • Visual Studio 2017 64-bit

Currently I haven’t rewritten the build script for CSFML, so I’m only supporting the following libraries at the moment:

  • SFML
  • Thor
  • SFGUI

Still not sure where I want to really go with this project, but for now I’m going to use to provide library versions with the runtime lib statically linked, since we aren’t providing those in the SFML downloads on the official website.

And I hope it’s of use to some people out there!

Convert EPS to SVG – Cisco Icons for yEd

I wasted like one or two hours on this and thought, I’d make a quick post, so others don’t have to waste their time in the future.

Convert EPS to SVG

If you just want to convert some EPS files to an SVG file, all you need is Inkscape and then use the following command to do the magic:

inkscape input-file.eps --export-plain-svg=output-file.svg

If you have a bunch of these files you can use the following command on Windows to convert them in one batch:

for %%f in (*.eps) do inkscape "%%f" --export-plain-svg="%%f.svg"

Of course Inkscape supports a lot more formats with a lot more options, just use the help flag to get the full list.

Cisco Icons for yEd

I originally ran into the problem, because I wanted to use the “standard” Cisco icons for a network diagram in yEd, an awesome and free graph editor. While googling I ran into this post which provides a set of Cisco icons for yEd, but the huge color difference between the icons just wasn’t acceptable (light blue vs “Cisco” blue). So I thought to create my own set and found myself converting the EPS from Cisco’s official Network Topology Icons page. I then converted them as described above, imported them into yEd and exported the full set for you to enjoy. There’s still some color difference, but less extreme. Since a lot of the icons are rather useless – or do you use some space router at home? – I’ve selected a few of the icons which seemed most useful to me and created a separate package. Note: The converted SVG files ares included.

Cisco Icons SVG + GraphML [394 KiB]
Cisco Icons (Selected) SVG + GraphML [41.7 KiB]

See this article on how to import the icons into yEd.

A look at CLion 1.0

For the development of Synth Guitar my Ludum Dare Compo entry I decided to use JetBrains’ CLion as my IDE. Ever since writing my most popular post about MinGW-w64 and an older EAP version I played around with the thought of trying it out, but never found the right project for it. For a year or two I’ve been using Code::Blocks, but was never fully satisfied (among others also because of this), however whether CLion will replace Code::Block for me is still open.

CLion

The Setup

Before I had the EAP (Early Access Program) version installed on my notebook, but for my desktop PC I got to newly install the full version of CLion. As a student I get a non-commercial license for free, not only for CLion but for most of JetBrains’ products. If you however want buy CLion you’ll be paying €99 for a personal and €199 for a commercial license.

The download was very fast and with 138 MiB acceptably small. In comparison the offline installer for Code::Blocks with a compiler is 98 MiB and for Visual Studio you’ll be spending 6.9 GiB of your bandwidth, because Microsoft unfortunately doesn’t manage to provide a version just for C++.

CLion Setup

The setup is very simple and I quite like the settings part when starting CLion for the first time. It allows you to directly change the options for design, version control integration and proper compiler detection. The later is one of the strong points compared to Qt Creator or Code::Blocks, because CLion supports and properly detected my MinGW-w64 installation, while it always seemed a bit of a hassle with Code::Blocks or you first needed to learn how Qt Creator actually handles toolchains and compilers. I wonder though why JetBrains couldn’t fully “support” the latest builds of MinGW-w64, not even with their 1.0.1 update. Then again I ignored the warning you get for it and have yet to run into any problems because of that. However CLion has stated that it can lead to freezes in certain situations.

The Build System

As someone who quite likes CMake, CLion’s native support is amazing and something I’ve been looking for quite some time. Of course Qt Creator comes with CMake support as well, but last I tried it, it did not integrate very well. With CLion you write your CMake code, link your favorite libraries through it and it will build and run just fine. One thing that seems a bit strange compared to most other IDE is, that CLion keeps by default all the build files in a temporary directory somewhere in your user directory. I mean it makes sense to not spam the source directory with all the CMake temporary files, however every now and then one might want to do something specific with the binary and has to go search it in there. My assumption is that CLion expects you to install the binaries instead. Luckily the directory can be changed with a few simple clicks if you know where to look.

One of the strange default options CLion ships with is that it allows multiple instances of the application to be run. So when you for example are debugging, you can also click on run again and the interface will switch to a different layout but still keep running in the background and a new instance will be loaded. During the Ludum Dare Compo I didn’t figure out that there’s a stop button if you switch to the correct tab, thus I ended up killing off GDB manually. I’m however really glad that pressing the stop button works, because pressing the stop button with Code::Blocks most of the time simply doesn’t work and you end up having to kill the process in the task manager. After the Compo I got a response from CLion that there’s an option to only allow one instance. This should in my opinion be the default setting given that single-instance applications are a lot more common.

The Editor

I had been using Vim for some web development during a year or so and gotten quite used to some commands, however I’m still not a Vim guru, but can’t argue with the fact that it can accelerate the code-writing quite a bit. As such I tried out CLion’s Vim-Emulator and I’ve to say it’s very good. My main critique would be, that it’s not obvious in what mode you’re currently in, as such it’s really annoying when you start typing commands or text and only then notice that you’re in the visual mode. I honestly never had that issue with Vim, so all I can assume is that the indicators aren’t well placed. Something else that got me quite annoyed is that in almost all cases when you click on the editor to get the focus back, it will (accidentally) switch to visual mode. This usually lead me to keep hitting the ESC key multiple times just in case, to ensure that I ended up in command mode. Since the Vim-Emulator is a general JetBrains’ feature and not strictly related to CLion it might also just be me, who isn’t used to it.

I’m not a big fan of getting my code automatically formatted, since my style usually doesn’t match with the coding style of a lot of other C++ developers. Until I realized that CLion allows you to customized the formatting rules to about every detail, it was quite annoying to work with at times. But the customization settings are in fact so detailed that you have to be careful to not overlook the option you actually want to change. What was a bit counter intuitive however is that in order to make any changes to the formatting, you first have to create a new style setting. The ones that are installed by default are read-only. Some indication for that would be helpful and would’ve saved me a trip to the all-knowing Google.

Performance

Performance is one of my main concerns with JetBrains’ IDEs. CLion is written in Java and even though they do a great job at hiding that fact, meaning the application doesn’t feel nor look like your standard cheap Java application, the resource allocation regarding RAM and CPU time is something you might not want to overlook. To be fair though, it’s impossible to tell whether Java itself has much to do with it or if there is more improvement possible in CLion’s codebase alone.

When opening my Ludum Dare project and just letting CLion sit there, the memory allocation idles at around 1000-1200 MiB. I assume most of it is used for source code meta information to make auto-completion or similar things faster. However Synth Guitar only uses SFML as library, which makes me wonder how the memory allocation scales for larger projects with a lot of different libraries. Personally it doesn’t seem like a big issue, after all there’s plenty of free RAM and it certainly is a better alternative to keep that data in memory compared to Visual Studio’s huge IntelliSense database files.

Something that got a bit of an issue during my Ludum Dare live stream, was the CPU usage of CLion. It’s nice to see CLion using no CPU time at all, when doing nothing, but it gets quite scary when you look at it while writing code. It will jump all over the place starting off at around 30% total CPU allocation and when you start compiling something it actually maxed out my CPU. If you do CPU-heavy things like encoding live stream video and audio data at the same time, such a high CPU load can become a bit of a problem. Again it’s just a speculation, but I’d claim that optimized C++ code instead of Java code, would reduce the CPU usage for the general editing part quite a bit.

Synth

Refactoring

Having worked with CLion for only a short period of time, it’s kind of hard to talk about features, since I have yet to discover most of them and put them to use. But since we’re talking about JetBrains here, I think the most talked about feature is their refactoring tool. I’m very used to manually refactoring everything and as such will first need to get used to the option of having code changed automatically, as well as learn what the tool can actually do. Something that I tried to do was rename my copy of a class, but apparently that’s still a missing feature. It might have been just my lack of knowledge, but using the refactoring tool with the Vim-Emulator seemed to cause some trouble.

Conclusion

CLion is a solid IDE for C++ development. You really notice the long experience JetBrains had with building code editors and yet they still managed to keep up to date with the “latest tech” (Git, CMake, MinGW-w64, etc.). I really hope that performance will improve a bit and am sure that some of these early bugs and missing features will get fixed over the next few months. I wish the developers of Code::Blocks and similar IDE would take a look at the look and feel of CLion and try to aim for that as well. Especially Code::Blocks seems to not have improved noticeable over the past years, which is quite a shame.

Everyone who works a lot with CMake should really give CLion a shot. I already started another project with CLion, so who knows maybe Code::Blocks will slowly drift into the “unused” section of my PC?

As a final note: JetBrains has in the meantime released version 1.0.1.

How to use MinGW-w64 with CLion

Update 29.09.2014: As pointed out by Anastasia Kazakova in the comments, CLion’s EAP has received an update which added native support for MinGW-w64!

In the past few days, I’ve seen CLion mentioned on multiple locations including the SFML forum. CLion is a new IDE developed by JetBrains for CMake based projects, it supports multiple languages and can be further extended with plugins. Some might recognize the interface since it’s very similar to JetBrains’ popular Java editor IntelliJ IDEA.

CLion

Personally I haven’t really looked at the IDE in-depth, since JetBrains is the creator of the allegedly awesome ReSharper tool for Visual Studio – which I’ve never used – the IDE itself should provide some pretty decent refactoring capabilities. Last I checked out Qt Creator, I was a bit disappointed at the sluggish CMake integration; this at least seems to work a lot better with CLion. However maybe Qt Creator upped their game since then as well.

This post however shouldn’t really be about introducing/promoting CLion and maybe some or many of you who somehow find this post already know what CLion is, instead this should actually be a short tutorial on how to use a compiler of the MinGW-w64 family with CLion.

Tricking CLion

For whatever reasons the developers at CLion apparently didn’t get the memo, that the original MinGW has been relatively abandoned and most of the user base has moved on to the MinGW-w64 project, which originally was created to develop a 64-bit compiler, but now supports both architectures. As such CLion currently only officially supports the vanilla MinGW. As a MinGW user for many years, the fact that CLion only wanted to recognize the original MinGW as compiler seemed rather odd, since the differences in using either a MinGW or a MinGW-w64 version nearly doesn’t exist. When I ran ProcMon and tracked what in the filesystem CLion accessed, I noticed that it checks for the existence of include/_mingw.h. By providing such a file in your MinGW-w64 directory structure you can trick the compiler into accepting it as MinGW compiler.

How To

Here are the few steps to make it work:

  1. Get your MinGW-w64 compiler installed somewhere.
  2. Create a file with the path [MinGW-w64 dir]/include/_mingw.h and the content shown below.
  3. Point CLion to your [MinGW-w64 dir] and watch how CLion recognizes your MinGW setup.

_mingw.h

#ifndef __MINGW_H

#define __MINGW_H

#define __MINGW32_VERSION           3.20
#define __MINGW32_MAJOR_VERSION     3
#define __MINGW32_MINOR_VERSION     20
#define __MINGW32_PATCHLEVEL        0

#endif /* __MINGW_H */

Disclaimer: CLion is still in an Early Access Program and may change any day. This trick worked for me, but there’s still a chance that it might not work for you.

To end this write up, here’s the introduction video from JetBrains on CLion – it was posted on their blog.