General Development Archive

If you've followed any one of the amazing tutorials on how to set up a mainframe on a conventional personal computer, you've probably noticed they end with the login screen as if everything beyond that point will be intuitive and self-explanatory to newbies. I mean... That was my assumption going into this project. I'll figure it out. How hard could it be? Maybe it would take me a few hours. Maybe I'd have to Google some stuff... Read some documentation...

It took me over a week.

Over a week to figure out enough to compile and run a basic program.

Looking back at the past three years, React Native has proven to be extremely successful at Discord and helped drive our iOS user adoption from zero to millions!

More specifically, React Native has allowed us to reap the benefits of quickly leveraging reusable code across platforms, as well as develop a small and mighty team.

Meanwhile, we've learned to adapt to its inevitable pain points without sacrificing overall productivity.

APL (A Programming Language) is an interactive language that allows access to the full power of a large computer while maintaining a user interface as friendly as a desktop calculator. APL is based on a notation developed by Dr. Kenneth Iverson of IBM Corporation over a decade ago, and has been growing in popularity in both the business and scientific community. The popularity of APL stems from its powerful primitive operations and data structures, coupled with its ease of programming and debugging.

Most versions of APL to date have been on large and therefore expensive computers. Because of the expense involved in owning a computer large enough to run APL, most of the use of APL outside of IBM has been through commercial timesharing companies. The introduction of APL 3000 marks the first time a large-machine APL has been available on a small computer. APL 3000 is a combination of software for the HP 3000 Series II Computer System2 and a CRT terminal, the HP 2641A, that displays the special symbols used in APL.

Okay, now for the big news: the basics of SIMD are now available! SIMD stands for "single instruction, multiple data".

The IRS has a lot of mainframes. And as millions of Americans recently found out, many of them are quite old. So as I wandered about meeting different types of engineers and chatting about their day-to-day blockers I started to learn much more about how these machines worked. It was a fascinating rabbit hole that exposed me to things like "decimal machines" and "2 out of 5 code". It revealed something to me that I had not ever considered:

Computers did not always use binary code.

Computers did not always use base 2. Computers did not always operate on just an on/off value. There were other things, different things that were tried and eventually abandoned. Some of them predating the advent of electronics itself.

Here's a little taste of some of those systems.

Programming time, dates, timezones, recurring events, leap seconds... Everything is pretty terrible.

The common refrain in the industry is Just use UTC! Just use UTC! And that's correct... Sort of. But if you're stuck building software that deals with time, there's so much more to consider.

It's time... To talk about time.

Embedded systems have started to become extremely complex. The big push to connect every device to the internet to create the IoT is causing a demand for embedded software engineers that has not yet been seen in recent history. This big push is causing a vacuum in which companies can't find enough embedded software engineers. Instead of training new engineers, they are starting to rely on application developers, who have experience with Windows applications or mobile devices, to develop their real-time embedded software. The problem, of course, is that these engineers don't understand the low-level hardware, but only high-level application frameworks that do all the work for them.

This doesn’t have to be forever. Maybe in the future, developers will start using React Native to build desktop applications. Or perhaps Flutter! Electron apps have a bad reputation for using too much RAM, have potential security issues, can’t (yet) match the speed of C++, and they often lack the polish and familiarity of a great native app.

But it seems clear to me that OS-specific SDKs are becoming a liability for desktop OS vendors. Developers want to use the technologies they know, and they want maximum reach for the products they build. And they’re smart enough to get what they want. A lack of cooperation on the part of Apple, Google, and Microsoft will only hurt users.

Say hello to your new Electron overlord.

I've decided to write up a little history of ispc, the compiler I wrote when I was at Intel. There's a lot to say, so it'll come out in a series of posts over the next few weeks. While I've tried to get all the details right and properly credit people, this is all from my memory. For anyone who was around at the time, please send an email if you see any factual errors.

Honestly, I don't think the Atari 2600 BASIC has ever had a fair review. It's pretty much reviled as a horrible program, a horrible programming environment and practically useless. But I think that's selling it short. Yes, it's bad (and I'll get to that in a bit), but in using it for the past few days, there are some impressive features on a system where the RAM can't hold a full Tweet and half the CPU time is spent Racing The Beam. I'll get the bad out of the way first.

Input comes from the Atari Keypads, dual 12-button keypads. If that weren't bad enough, I'm using my keyboard as an emulated pair of Atari Keypads, where I have to keep this image open at all times.

Okay, here's how this works.

In Visual Studio 2017 15.5 Preview 2 we are introducing support for cross compilation targeting ARM microcontrollers. To enable this in the installation choose the Linux development with C++ workload and select the option for Embedded and IoT Development. This adds the ARM GCC cross compilation tools and Make to your installation.

Our cross compilation support uses our Open Folder capabilities so there is no project system involved. We are using the same JSON configuration files from other Open Folder scenarios and have added additional options to support the toolchains introduced here. We hope that this provides flexibility for many styles of embedded development. The best way to get started with this and understand the capabilities is with a project exported from the ARM mbed online compiler. We'll cover the basics here, to learn more about the online compiler see ARM’s tutorials, and you can sign up for an account here.

This release is the result of the community's work over the past six months, including: C++17 support, co-routines, improved optimizations, new compiler warnings, many bug fixes, and more.

Later this year, on November 21, 2017, D-Bus will see its 15th birthday. An impressive age, only shy of the KDE and GNOME projects, whose collaboration inspired the creation of this independent IPC system. While still relied upon by the most recent KDE and GNOME releases, D-Bus is not free of criticism. Despite its age and mighty advocates, it never gained traction outside of its origins. On the contrary, it has long been criticized as bloated, over-engineered, and orphaned. Though, when looking into those claims, you’re often left with unsubstantiated ranting about the environment D-Bus is used in. If you rather want a glimpse into the deeper issues, the best place to look is the D-Bus bug-tracker, including the assessments of the D-Bus developers themselves. The bugs range from uncontrolled memory usage, over silent dropping of messages, to dead-locks by design, unsolved for up to 7 years. Looking closer, most of them simply cannot be solved without breaking guarantees long given by dbus-daemon(1), the reference implementation. Hence, workarounds have been put in place to keep them under control.

Nevertheless, these issues still bugged us! Which is, why we rethought some of the fundamental concepts behind the shared Message Buses defined by the D-Bus Specification. We developed a new architecture that is designed particularly for the use-cases of modern D-Bus, and it allows us to solve several long standing issues with dbus-daemon(1). With this in mind, we set out to implement an alternative D-Bus Message Bus. Half a year later, we hereby announce the dbus-broker project!