CppCast - Building Debuggers and Keyboards
Episode Date: August 17, 2017Rob and Jason are joined by Sy Brand from Codeplay Software to talk about building C++ debuggers and the hardware and C++ firmware of a custom keyboard. News N3886: A Proposal to add a Databa...se Access Layer to the Standard Library C++ London "University" C++17 Features and STL Fixes in VS 2017 15.3 The reviews have begun Links minidbg - A mini x86 linux debugger for teaching purposes Building my first custom keyboard Accelerating your C++ on GPU with SYCL Codeplay Software Sponsors Backtrace Hosts @robwirving @lefticus
Transcript
Discussion (0)
This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building.
Get to the root cause quickly with detailed information at your fingertips.
Start your free trial at backtrace.io slash cppcast.
CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community.
Get your ticket today.
Episode 114 of CppCast
with guest Simon Brand, recorded
August 16th, 2017.
In this episode, we talk about the changes in the latest Visual Studio update.
Then we talk to Simon Brand from Codeplay Software.
Simon talks to us about building debuggers and keyboards. Welcome to episode 114 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob B rob berving joined by my co-host jason turner jason how you doing today i'm doing all right
rob uh we i guess technically things went all right last week after we said that there might
be some audio problems so uh maybe we'll continue experimenting some more in future weeks yeah i
don't think i heard any complaints about the audio from last week.
Good.
Yeah, you tried out the web Skype client on Linux and found it to be pretty adequate?
Yes, I would say for people who are on Linux, if you're interested in using Skype,
the web.skype.com is definitely the best option over trying to get some official download to work or something.
Yeah, the Linux desktop client is just really, really far out of date, right?
Yeah, apparently.
But we had no problems with multiple video Skype calls
and file sharing and all kinds of things using the web client last week.
Awesome.
Well, at the top of our episode, I'd like to read a piece of feedback.
This week we got a tweet from TJ Chip,
and he's actually just sending us a link to um a paper
that he thinks we might be interested in talking about and he asked is there much interest in
adding a standard database access library as proposed in this link and i'll put the link
in the show notes of course and this is paper3886, a proposal to add a database access
layer to the standard library. And I'm not really sure how I feel about this, Jason. I'm interested
in what your thoughts are on it. Obviously, we have, you know, standard file system coming in
C++ 17. But I'm not really sure if a SQL client built into the C++ standard is something we need.
I feel like we have enough libraries for that.
Yeah, I mean, all of the Java and C Sharp, I guess,
have standard ways of doing these things.
It would be pretty low on my list,
although I could see maybe perhaps a generic kind of way,
just like a data access layer of some sort.
And then it would be up to implementations
as to what backends, if any, they supported.
But I don't know.
I haven't spent a lot of time thinking about it.
Yeah, to give you a little snippet,
it says this document describes
an easy-to-use database abstraction layer for C++.
It describes a set of classes which can be used
to access an arbitrary SQL-based relational database system.
So it's calling itself database abstraction, but it is saying
specifically for SQL.
Right.
Yeah.
It's interesting to see
what other people think about it, but
my initial thoughts are just that
it would be kind of lower on the priority list.
There's plenty of other things C++ needs first,
I would think.
I would agree, yes.
Well, we'd love to hear your thoughts about the show as well.
You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com.
And don't forget to leave us a review on iTunes.
Joining us today is Simon Brand.
Simon is a GPGPU toolchain developer at CodePlay Software in Edinburgh.
He turns into a metaprogramming fiend
every full moon when he can be found
bringing compilers to their knees with template
errors and debating undefined behavior
on the C++ Slack channel.
He co-organizes the Edinburgh
C++ user group and contributes
to various programming standards bodies.
Outside of programming, he enjoys experimental films,
homebrewing, and board games. Simon, welcome to the show.
Hi, thanks for having me.
So let's talk about this metaprogramming fiend that you turn into every full moon.
Yeah, so I got interested in metaprogramming
quite soon after I got into C++.
I guess I learned most of my knowledge on metaprogramming
by going on Stack Overflow, answering questions incorrectly,
and having people tell me why I was an idiot, essentially.
Well, I've never heard of that method of educating yourself.
That sounds pretty...
It's pretty surprisingly recommended, actually. It worked pretty well.
It seems kind of intense
I have to have a thick skin for that I guess
yeah
the MED program has always been an interest
of mine I love the idea of
the kinds of abstractions
you can build with it and
the power
it can give you for building higher level abstractions
to map down onto more efficient
code in the low level,
which is what I've been doing a lot with my mechanical keyboard framework,
which maybe we can talk about a little bit later.
Yeah, we'll definitely talk about that later,
but do you use these advanced metaprogramming techniques
in your day-to-day job as a GP, GPU tools developer?
Bits and pieces.
They come up from time to time if we're
trying to build reusable
components that we can use across
some of our different toolchain
elements. So we have our own
internal libraries
which we try
and make sure they're unit tested and
high quality and reusable.
So we have to use a lot of templates for that.
And then particularly the SQL standard which have to use a lot of templates for that. And then particularly
the SYCL standard, which we work on a lot, is a very heavily templated C++.
I'm not familiar with that, I don't believe. What is that?
So SYCL is a high-level single-source C++ programming model for heterogeneous systems
and parallelism. So if you're familiar with OpenCL, it's kind of a higher level than OpenCL.
So similar to CUDA, but it's all built using completely standard C++.
Interesting. And it supports, I guess, OpenCL or whatever GPU hardware on the back end?
Yeah, so the idea is it's mostly commonly associated with OpenCL,
but you could have other backends,
so things like HSA or maybe Vulkan Compute, things like that.
Okay, interesting.
That's a technology we're working with a lot
and using it to port things like TensorFlow over to OpenCL
because it's a much nicer programming model to work with
rather than OpenCL, which is quite verbose at times,
shall we say. I have not actually done any GPU programming at all myself. And maybe, again,
this is something we could talk about a little bit later, but do you have any recommendations for
someone who wants to get started in GPU programming? I think having a look at some of the tutorials on the AMD website,
if you're looking for OpenCL or the CUDA website,
sorry, on their various CUDA tutorials.
I also did an introduction to SYCL blog post on my blog,
so that's a good one to look at.
It's meant for the C++ programmer rather than the GPU programmer.
So maybe that's even a good resource to get started with.
Okay. And what is your website again?
blog.tartanlama.xyz
Okay.
You'll have to include a link to the Sickle blog post.
It's interesting learning a little bit more about that.
So Simon, we've got a couple news articles to discuss.
Feel free to comment on any of these,
and then we'll start talking more about your keyboard
and your interest in debuggers and everything else you've got going on.
Okay?
Yeah, sure.
Okay, so this first one is actually a post
on the C++ London user group's message board on meetup.com.
And they're trying something new
where they're going to be putting together
what they call C++ London University.
And the basic idea is that they recognize that the average user group attendee
is already pretty experienced in the language,
but they occasionally get people coming in who maybe are still students
or they're just programmers who are more familiar with other languages and
they want to learn a little bit more about C++. And they're trying to put something together to
target those types of attendees who want to just learn more about C++ from more of a beginner
level. And their idea is to put together this kind of like coding dojo type thing where
newer programmers could be paired with more experienced members of the community. It sounds like a pretty
good idea, and I was wondering what your thoughts were on this, Simon, as an organizer
in the Edinburgh user group. Yeah, I think this is something
which is really valuable. We've talked about it briefly quite recently for our meetup
as well, having something which is more aimed at beginners
because we'll have a time at the start of our meetup as well, having something which is more aimed at beginners, because we'll have a
time at the start
of our meetup where we say, oh, so what's
everyone interested in? Why are you here?
And a lot of people say, oh, I'm a
student, or I'm just learning C++, and
I want to kind of get more of a feel for language.
And we say, great, you're very welcome here.
And then we have two talks on
crazy metaprogramming tricks, and I have no idea
what's going on. So I think something like this is really valuable,
and they have some great teachers and speakers
in the C++ London group.
So I think it's a really good idea,
and I hope it goes really well.
Maybe we can steal it for our Edinburgh group.
Let them prove it for you first.
It is true that the C++ London community as well,
I mean, lots of friends of the podcast anyhow, shall we say.
There's lots of people who we know there.
Yeah, definitely.
Okay, next one is from the Visual C++ blog,
and this post is C++ 17 features and and STL Fixes in VS 2017 15.3.
And this article is authored by STL.
And one thing I noticed immediately when breezing through the article
is a numerous meow and kitten references,
which I don't think I would have noticed without talking to STL
during our interview a couple months ago.
But now they really jump out at you.
Yeah, I didn't even actually realize that STL was the author, although I think I probably assumed that he was.
But as soon as I saw the first meow, I'm like, yep, definitely STL.
But there is a lot in this. Yeah, apparently this 15.3 release is supposed to be pretty big
as far as new C++ features and improvements come.
And this is just one of, you know,
they'll kind of do like a blog post dump right before a release.
And this one came out five days ago.
And then there were four more posts three three days ago i think about the new features
in visual studio for c++ developers um so definitely encourage everyone to to go and
check those out i actually just upgraded to 15.3 i started a few minutes before we got on the air
and it just finished up well and also we didn't mention uh that GCC 7.2 was just released a couple of days also ago, something like 90 bug fixes in it.
Wow.
But I do have a couple of questions about this Microsoft update.
The first one, and the correctness fixes, fixed missing specialization of autopointer void.
That was my favorite one, definitely.
Isn't autopointer officially removed in c++ 17 yeah so i guess i don't know if this is a back port for um if you're
running it in a older standard yeah i think i saw something about this in the comments actually and
and they did say that they're fixing it for c++ 14. That still was never a good idea.
Sure.
Yeah, and that's true, I guess, in later,
the most recent versions of MSVC,
you can actually choose which standard you want finally.
Yeah.
Yeah, it made me laugh.
Okay, and then this last article is from Meeting C++.
And I think we talked just a few weeks ago about this idea that Jens Weller started with C++ reviews for libraries
that don't necessarily want to get involved with something big and kind of complicated like Boost,
but they want to get some feedback on their libraries.
And he put together this new subreddit called CPP Review
and if you are interested
you can now go and submit a comment
after looking at these two first libraries that are for review
Bulk and Dynamics
and I checked the subreddit and both of the posts
do have a couple comments
with people giving feedback.
I think Dynamics was getting a bunch of good feedback
and people saying that they accept the proposal.
Yeah, one of the things I liked about the review of Dynamics
was the reviewer who called out,
like, they made specific comments on CMake usage in there
and how to apply best practices into the CMake also,
which is I think people are becoming more aware
of the fact that you need to be, you know,
using best practices and treating your build tools,
you know, seriously.
But I thought it was good to see someone
reviewing the CMake file also.
Yeah.
Yeah, I know one thing Gore brought up when we had him on
and we mentioned this was he was a little concerned
that maybe there wouldn't be people willing to, you know,
spend some time reviewing these libraries.
But it seems like, at least initially,
that it is getting some attention and some interest in doing it.
So that's good.
Yeah.
I think my only real concern looking at the first reviews
is that they need to have some
kind of shared idea
of how much time should be spent
on reviews or the kind of amount of
feedback they should have because you look
at them and I think at least when I
looked at one of the reviews was this
long really great list
of points of pros and
cons and constructive
feedback and it was obvious that the author had spent
a lot of time looking at the library
and constructing feedback
and then there was another review
which was just, yes it's good
except
and Jens said
in his original post
that he wanted this to be
that you have a badge to place on your library
or something saying saying oh this is
verified by the C++
review community
I think if that is to hold
any weight then there needs to be
a good idea
of quality in the reviews
otherwise it's just a
badge which
anyone could
achieve if they appease enough people on the Reddit.
Right.
Yeah, from that standpoint,
it doesn't seem quite as rigorous
as the boost review process, I guess,
which we've talked about a lot lately.
Yeah.
But it has different goals, too.
Sure, yeah.
And we're actually going to have Jens on,
I think, next week,
so we'll definitely be talking more about this, I'm sure. Oh, too. And we're actually going to have Jens on, I think, next week.
So we'll definitely be talking more about this, I'm sure.
Okay.
Okay.
So speaking of meeting C++,
you're going to be speaking there in a few months, right, Simon?
Do you want to tell us a little bit about what you have planned for your talk there?
Yeah, sure.
So I'm going to be speaking on how C++ debuggers work.
So it's quite a large topic, especially this will be my first talk at a major conference like this. So I definitely started small.
My main idea for it was, so I got into debuggers in my first
job which is at Codeplay
my first project was
maintaining a compiler
and debugger for OpenCL
and the first thing I
thought was well I know nothing about debuggers
so I'll go and research them
surely there should be some great resources
on how debuggers work
and turns out there aren't
there are a handful of posts um
eli bendersky i don't know pronounce his name but he has a three um a series of three blog posts
about um debuggers which is quite excellent but they don't actually show you like here's how all
of these different pieces work and fit together and here's how you would actually write a debugger and things like that.
So I ended up just reading the sources for LLDB and learning that way.
And now, like four years later,
I'm now in a position where I actually do know quite a lot about debuggers.
And so I was talking with some of my colleagues and saying, oh, yeah, there's still not any great resources on debuggers there.
Actually, you know what, I should make some.
So this Meeting C++ talk is part of that
and then I also have a 10-part blog post series
on writing a debugger for Linux.
So it goes all the way from starting the process
to setting breakpoints on addresses
to setting breakpoints on source lines and function names and reading variables.
And then it goes off on some advanced things that you might want to add yourself, like threading support or shared library loading and things like that.
So I tried to cover all of the major topics that people would want to know about debuggers.
And then this talk, I mean, C++ is hopefully going to be a kind of video which I could send to people as a good resource for the company as well.
If we get a new debugger project and we need people and they don't know about debuggers, we can say, well, read this talk.
Sorry, watch this talk. And that can be a good starting point.
So that was the kind of aim for it.
So there's a handful.
I mean, there's at least GDB and LLDB.
And I know a couple other lesser-known debuggers
that are open source.
Kind of curious why you decided to start
by reading the source to LLDB specifically.
Yeah, so that's a lot because all of the toolchains which we work on
at CodePlay are LLVM based
so the
debugger projects
that we do are built on top of LLVM
so it made sense to
read the sources in order to
understand debuggers and also
LLVM because they would have to work on it
but LLVM is also
quite nicely architected for the most part
and has a fair amount of explanation,
some of the header files and things like that.
So it was a good enough base to just kind of get stuck in
and start understanding things.
And you mentioned it was a 10-part article you ended up writing.
That's a pretty big commitment.
Yeah, it took me about three or four months. I ended up with that's a pretty big commitment yeah it took me about
three or four months ended up about 10 000 words or something so uh yeah it took a while did you
know it was going to be 10 parts when you started um no i originally planned it to be three and i
said oh i want to write about this and i want to write about that and i need to go into more
details about this and yeah so it it got out of control a bit yeah when i heard 10 parts i wondered if this was one
of those projects where you wouldn't have started it if you had known how big it was going to end
up being yeah that's probably right what are uh some of the more interesting things you learned
about you know programming while writing these C++ debuggers?
I think the most interesting one was when I started the blog post series, I knew pretty
much all that I wanted to write about beforehand, and I understood all the concepts already.
I just had to put them into words.
But the one thing which I never understood, could never quite get my head around,
was how the debugger traced loading of shared libraries on Linux.
So I had a look at the sources for LLDB
and just did not understand it at all.
I knew it relied on some arcane communication
with the dynamic loader,
but I had no idea how it actually worked.
So eventually I said, okay, right,
if I'm going to write these posts, I need to understand this.
So it turns out that the dynamic linker
puts a structure into the processes address space,
which is updated every time a shared library is added or removed so it has like a linked list which is
stored in your program's address space and you can go and parse that to look at all of the shared
libraries which are loaded then the really interesting thing is how do you get told when
something is loaded or unloaded so the structure also has an address in it,
which points to a function which is called
every time a library is loaded or unloaded.
So internally to your debugger, you can set a breakpoint on that.
And when you hit that breakpoint,
you know that there's been a change
and you can read the linked list
and update your internal data structures.
So that was kind of a really fascinating point for me to finally understand.
And when it clicked, I was like, okay, I know how to implement this now,
and I could build a little proof of concept and things like that.
So that felt good when I finally got it.
So to make sure I understand that, that linked list is in every Linux process,
regardless of whether or not it's being debugged um yes i think anything which is um links against any dynamic libraries um right maybe even
not i'm not sure if it would eliminate it it's essentially the the underscore dynamic section
of the elf file is okay the process so anything which has that
on linux will have this this structure and then the debugger just takes advantage of that fact
yep cool so how uh excuse me how has working on this debugger changed the way that you program
c++ i don't think it's so much changed how I program,
but it's certainly helped me understand and use the tools more effectively,
particularly when there's a problem.
So actually shortly after I was looking into this dynamic loader thing,
I was doing some remote debugging with GDB,
and I got this error message it said oh error cannot find the um dynamic linker function to set a breakpoint on it i know what
this means now i wasn't just like frantically googling for something which i didn't understand
i actually had some context to base it off of and I knew what the debugger was trying to do, and I knew why it was failing, and I could then go and make the necessary changes to make it work.
Whereas if I didn't know, I would just be like, Google error message, and it would probably give me the same your experience but to me it seems like that kind of
error is the kind of thing that you would find three people who had the same problem 10 years
ago and they never posted the solution oh never mind i fixed it right no
after learning all this info you have now about debuggers did you make any like contributions to either ldb or gdb or anything like that um i haven't yet i would like to
um do some work on ldb which can actually be upstreamed um most did some work on it as a prototype
to debug HSA systems,
which is another heterogeneous programming standard.
But it was very much a prototype
and wasn't able to get upstreamed.
I think I would like to work some more
on the threading model of LLDB.
There are a few things that GDB has which LLDB doesn't,
or at least has a better support for.
Non-stop mode is one of them.
So when you can have some threads,
one thread stopped while the others are all running,
LLDB kind of supports that,
but it's mostly just in the
remote backend rather than actually
reflected in the threading model of
LDB. And then GDB
also has a really nice follow forks mode
for if you're
forking off some child processes
and you want to decide, actually
now I want to debug the child rather than
the parent. GDB handles that
really nicely, so it would be nice to stick these things in LDB as well.
And maybe building on Rob's question,
in a more general sense,
is there anywhere that you see that
debuggers could be improved
to make debugging C++ experience better?
I think a lot of the reversible debuggers,
like RR and UndoDB and things like
that
they're definitely going a really good way
to
solve a lot of the problems with
more traditional command line debuggers
I think that a lot of the problems
going forward as we move to more heterogeneous
systems will be having
debuggers which can handle
multiple architectures on the
same system.
I've spent
a lot of time on standards
calls talking about this, and I do think
that the best place to build that in is
at the operating system level.
But getting
those are some big changes, and getting
those into the Linux kernel and things
like that would be difficult.
So I think that's a,
an interesting path,
which more research needs to be put into.
Great.
I want to interrupt this discussion for just a moment to bring you a word
from our sponsors.
Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation
throughout the software error lifecycle. Spend less time debugging and reduce your mean time
to resolution by using the first and only platform to combine symbolic debugging,
error aggregation, and state analysis. At the time of error, Backtrace jumps into action,
capturing detailed dumps of application and environmental state.
Backtrace then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more.
This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments.
Join industry leaders like Fastly, Message Systems, and AppNexus
that use Backtrace to modernize their debugging infrastructure.
It's free to try, minutes to set up, fully featured with no commitment necessary.
Check them out at backtrace.io.cppcast.
Do you want to tell us a little bit about the custom keyboard you worked on?
Yeah, sure. So there are actually two of them now.
I started a new one.
I'm right down that rabbit hole.
The first one I did was a small 40% keyboard,
so it didn't have your function key row or your number row,
and it didn't have a numpad,
and it had maybe a column shaved off
or something. So it was very small
because I wanted something portable which could be taken to
conferences and things like that.
So I had to design it right from
scratch. So there's
a great site online where you can
visually design
your keyboard layout
and then it will generate you a
CAD drawing which you can send to
like custom laser cut shops and things like that so I did that I got CAD drawings for these plates
and got aluminium plates cut at some place down in Cornwall and then they sent the plates up and
I got switches from States and then just hand wired the entire thing
so it's i'm using a tnc2 which runs a abr chip so everything every column and every row
is just soldered together and then soldered to the microcontroller and it has diodes everywhere
to prevent um like you pressing some keys another one showing
up that was a really cool project um my one problem when i did the kind of first pass of it
and i got everything working and i got uh the basic firmware done using this um tmk framework
because i was very um annoyed that the framework was all C
and all macros everywhere.
So I spent a lot of time debugging my keyboard,
which was debugging these things is horrible at the best of times.
There's an entire column on my keyboard which wasn't working.
It took me ages to work out.
I just missed a comma somewhere and a macro was screwing up.
Oh, my.
If this was all in C++ with templates, this would be so much better.
I was like, maybe I could build something which is better with C++.
So I spent a few weeks writing firmware for C++ 17.
So it's all, you give a kind of high-level description of your keyboard.
So you say which pins on the microcontroller your columns and your rows are soldered to,
and you tell it which parts of the matrix have keys soldered them and which ones don't,
because keyboards usually aren't just like a straight matrix.
They're staggered and have keys missing in different rows and columns and things like that.
And then you have to tell it what your key maps are.
So you do that at a really high level with just enums and variadic templates.
And then the library generates all of the codes to actually run the
firmware because it's all done at compile time and with templates it's actually got a lot of
room for optimizations so as i noted where some keys won't actually be present in your matrix
in most c firm firmwares they would loop over all of the keys
in your keyboard and say okay well
do I need to test this key?
Yes or no? Do I need to test this key? Yes or no?
Do I need to test this key? Yes or no? And they'll do this
every single time
whereas they're always making the same decision
it's just they're making that
decision at run time
whereas with my
C++ firmware
at compile time I can say do I need to test this key ever at runtime. Whereas with my C++ firmware, at
compile time, I can say, do I need to test
this key ever? And if I
don't, then it's never ever tested
and it doesn't get into the final code.
So you can actually...
We should take a quick step
back. So each
key on the keyboard is not individually addressable.
You've got rows and columns,
you're saying and so
how are you actually testing to see if a key is been pressed so you test the keys being pressed by
um i said this is simplified but essentially every key makes its own circuit with the microcontroller. So if you send power down
some row
and then test to see if you get
any
current at the
relevant column for the key you're
trying to read, if you get current
and the key is pressed because that closes the circuit
and if you
don't get any current and the key is not pressed
because the circuit's still...
The switches are just
closing the circuit or opening the circuit.
Okay. And so you just do that for every single combination of row and column.
Okay.
So you're saying with your firmware you you are able to, at compile time, optimize away testing for spaces that you know are impossible to ever happen.
Yeah, exactly.
Were you able to show any empirically how more efficient your version is than the C version or anything like that?
I haven't. It's something that I would like to do, some of the problem with this application of mechanical keyboards is if the user doesn't notice it, then it doesn't really make a difference.
I mean, you can say, like, oh, I can do so many different loops of my, of reading my
keyboard or in such and such a time, but if it doesn't make a difference to the user,
then it's not really making a difference.
But I still thought it was an interesting approach
of just a high-level template description
and trying to get as optimal code as possible.
I think for the mechanical keyboards,
there's more usability of the API,
which is the good thing to come out of it.
But I think there would be a lot of other applications
where you could have kind of template-based embedded domain-specific languages,
which you can use to very aggressively optimize the final code.
So the AVR that you're using for your control, that's an 8-bit CPU, right?
I literally do not know.
Okay.
But it's a very tiny platform regardless.
Yeah.
And no problem modern C++ compiler with it.
Yeah, I mean, I don't...
I just built GCC from source, and I can't use any.
But the standard library for C++.
So anything I needed, I just wrote myself, and it was fine.
Right. Cool.
So you said you built the first keyboard as a really small, portable one that you could bring with conferences.
What's the second keyboard you're working on?
So the second one is a split-hand,
which means that it essentially looks like two keyboards one for each hand and they're connected by an audio cable um so split hands
and each hand is kind of a pooled ergonomic design so if you've ever seen the Kinesis Advantage I haven't.
I think I know something about that.
Yeah, it's quite a popular
well, relatively popular
mechanical ergonomic keyboard.
This is kind of like
the Kinesis Advantage but
instead of one unit, it's one unit
for each hand. So it's a lot smaller
takes up a lot less
desk space and I can choose all the
switches myself and things like that but it turns out because the the keys are in a kind of pool
rather than just um flat on your desk it's really difficult to hand wire especially if you
have terrible soldering skills like I do.
You said you ordered your key switches from the US.
Are you able to get high-quality keys?
Yeah, there's, as I said, deep rabbit hole.
There are whole communities dedicated to these things. People build custom switches and get exactly what they want and things like that.
So, yeah, it goes deep.
But you did not go the route of building custom switches yourself?
I did not.
I did get some community-designed ones, and they are very, very nice.
Interesting.
I'm also curious about the interconnect.
You said you're using an audio cable between the two halves?
Yeah, so it has a microcontroller on one hand and then an input-output expander on the other hand.
So it communicates through that. And then the audio cable just so happens that it has enough wires to communicate easily. Okay. Maybe this is a silly question,
but could you have made the two halves each individually
their own separate USB keyboard effectively?
You could, and I think some split keyboards do that,
but if you want to hold down a special modifier key
and have that change the layer of your keyboard
then it's best to do that with a single microcontroller because otherwise you'd have to
like communicate with the operating system to say okay i press the special modifier and this should
change what the other keyboard is saying so it's easier to do if it's just one single controller
so generally speaking if you have multiple keyboards on a computer,
they're completely independent from each other.
Like if I hit caps lock on one keyboard,
it's not going to turn on caps lock on the other keyboard?
Or do you know?
No, that probably would turn on caps lock
because the normal modifiers are built into the USB protocol.
It's only if you had special layers on your keyboard that you would need something like I was describing.
So if you had to implement the USB side of it yourself, or is that something built into the platform you're using?
That's something where I found a very shady-looking C implementation.
Which I should probably rewrite at some point.
But on the operating system side, it's a standard USB HID device or whatever.
Yeah, exactly.
Okay.
That's really cool.
Yeah.
Do you want to tell us a little bit about the work you do at Codeplay Software?
I don't think I've heard too much about that company before.
Yeah, sure.
So, as I said, we work on heterogeneous platforms.
So, we're very involved with the Kronos group and specifications for bringing parallelism to as many systems as possible. I said Cicla is kind of one of our main targets at the moment because we quite firmly believe that as the industry moves towards
having more specialized hardware for more specialized domains,
you need to have some high-level programming model
in order to get performance portability.
So if you have lots of different vendors competing over different parts
and you don't want to train your programmers to code this programming model
for this component and this one for this one and this one for this one
and then integrate all of those programming models together,
you need a good high-level model.
So that's what we think sickle can support as it's a single source programming model so that
means that rather than something like open CL where you have your host code
which expends up your device and tells it what the arguments to your kernel are
and allocates memory and things like that and then you have your device and tells it what the arguments to your kernel are
and allocates memory and things like that.
And then you have your device code,
which is the actual code you want to run on your GPU and things like that.
And those are written in two different languages and source files.
So OpenCL has its own C dialect with its own set of built-ins and things like that.
But that's not a very nice programming model to work with
because you have to explicitly deal with the compilation of the separate language
and things like that, whereas SQL allows you to just say,
okay, here's a lambda or a function or a function object.
I want to run this on the GPU.
Here's how I want to run it.
Here's how the data should work.
And you let the compiler and the runtime figure it all out for you.
So it's a little bit different from CUDA as well.
In CUDA, you have to explicitly say, okay, this function is a device function.
I want to run this on device.
Please compile or compile this for the device.
Whereas on SYCL, you can say,
here's a normal sqls plus function,
and it calls some other sqls plus functions.
And it's up to the implementation to work out
every single function which you want to call on the device
and all the functions which are called by those
and then compile them separately.
So it essentially requires multiple compilers for the same program,
but all of the compiling for different devices
is just handled for you magically.
Wow. But you can use modern C++ stuff with it?
Yeah, so it's all C++ 14 and 17.
So, for example, there's an implementation of the parallel SDL using SYCL.
Okay. So is SYCL an open source project?
So it's an open standard
developed by the Kronos group.
Okay.
And so CodePlayer
might be a very heavy contributor
to the SYCL standard as well as OpenCL.
So what operating systems does it support?
So the Cycle itself is just a standard,
so it's agnostic to platform.
The implementation, which Codeplay have,
is currently only running on Linux.
Okay.
Sounds very interesting.
Do you maybe have any advice about running meetups?
I know you've been running the Edinburgh C++ user group.
Do you have any advice for people who might want to start their own user group?
Yeah, I think a lot of the considerations are the same as for any community physical meetup which you want to run. You need to have a venue which actually supports the number of people you want and the kind of talks you want to give.
Probably good to get some sponsorship, especially because sponsors will often help you find a venue or host it themselves if they can.
And then a lot of it is reaching out to speakers.
We've had some difficulties getting speakers at some points,
and then other meetups where, like, who wants to speak?
And we get too many people and we have to choose um so it's good to um if you do have to choose try and get a good
diverse range of topics and of speakers um so that it's not just as i said like here's a bunch of
crazy mech programming talks uh if you don't understand this well tough i think it's um the thing which i've most appreciated about
um the meetup which we've been running for um i guess a couple of years now maybe maybe one year
a while now is that um we actually have built up a sense of community so whereas at the start um we would have a meeting every few months
and you would see people and maybe you kind of recognize them and you would talk about something
and then you would go away and come back the next time and maybe talk to some other people
now we're at a stage where um people actually know each other they know what each other work on, they can talk about problems that they've been encountering,
get enthusiastic about C++.
So I think the community aspect is really the most important,
and that takes a lot of intentionality in how you format the meetup
and in the language that you use
and in the facilities that you have available.
And if you decide to go out somewhere after the meetup, things like that.
So I think those are the most important considerations for me.
So what would you say, I mean, specifically that we can do to try to build that kind of community in our meetings,
besides going out for beer afterward i think a lot of it is making sure that there's the space for the community to grow
um so if you if you just come in and you have some food maybe and then you have some talks
and then you go and there's no space for a community to grow.
You need to have a kind of intentional part of your meetups
where you say, okay, have a chat, get to know each other.
As an organizer, as a speaker, you can then go around this area
and try and get conversations started,
get people talking about what they're interested in because um a lot of people who come to our meetup um as soon as you
get them talking about something they're interested in like that's it you get great conversations for
for the rest of the meetup it It's all about making people comfortable enough
to actually enter into that kind of feeling.
Because if they're not comfortable,
then they're not going to talk.
Okay.
Okay.
Well, Simon, it's been great having you on the show today.
You obviously have a lot going on.
Where can people find you online
and read more about the stuff you're up to?
Yeah, so you can get in touch with me on twitter
I am at tartanlama
my blog is blog.tartanlama.xyz
and you can
the C++ Slack channel
on probably most of the sub channels which are there
so feel free to grab me if you want to ask any questions about
debuggers or
compilers or GPGPU
or keyboards or just
C++ in general.
Yeah, so those are probably the best
places to get me.
You do seem to kind of always be around
on Slack. It makes
me wonder what time zone you live in
or something.
I find it's a good way to um
like i'm stuck on a problem at work or something i can take a break from it and solve some small
problem that someone has on slack or something and then i can come back and i'm still thinking
about um programming and c++ and problems but it just gives me a break while still
learning things
and helping people.
Very cool. Yeah, for our listeners
who haven't checked out the Slack channels yet,
it is a great way to get
questions answered and meet other C++
developers.
Okay. Thanks again for your time today, Simon.
Yeah, thanks very much for having me.
Thanks for joining us. Thanks so much your time today, Simon. Yeah, thanks so much for having me. Thanks for joining us.
Thanks so much for listening in as we chat about C++.
I'd love to hear what you think of the podcast.
Please let me know if we're discussing the stuff you're interested in.
Or if you have a suggestion for a topic, I'd love to hear about that too.
You can email all your thoughts to feedback at cppcast.com.
I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter.
You can also follow me at Rob W. Irving and Jason at Leftkiss on Twitter. And of course,
you can find all that info and the show notes on the podcast website at cppcast.com.
Theme music for this episode is provided by podcastthemes.com.