26 May 2018

# Learning VS Code source

History / Edit / PDF / EPUB / BIB / 9 min read (~1639 words)

## 2018-05-26

• Read package.json to discover what packages VS Code depends on
• Observe the root directory structure, and more specifically the extensions and src directories which contain the bulk of the source code
• A lot of the code in the extensions directory appears to be dedicated to programming language support
• The remainder of the extensions seem to provide functionality for things that aren't "core" to vscode, such as configuration-editing, emmet, extension-editing and some color themes
• If you look at the .vscode/launch.json, you will find all the tasks that can be executed from within VS Code debugger. One task of interest is Launch VS Code which will take care of launching VS Code for us so that we may debug it
• In this file you will also discover that it runs \${workspaceFolder}/scripts/code.bat, which is the next script we'll take a look at
• In ./scripts/code.bat, we discover that this script will run yarn if the node_modules directory is missing, download the electron binaries if necessary and call gulp compile if the out directory is missing, then finally start the electron/vs code binary in the .build/electron directory
• We then start to look for common entry points file such as index.ts/js or main.ts/js, for which we find a match in the src directory
• We take a quick look around, trying to find where electron is likely to be instantiated... There's a lot of code in src/main.js that would be better elsewhere to make it easier to navigate this file
• Close to the bottom of the file we discover the code we are interested in as a call to app.once('ready', ...)
• Once the app is ready, we want to call src/bootstrap-amd and pass vs/code/electron-main/main as our entry point (per the signature of the exported function in ./src/bootstrap-amd)
• Here we can go to two places, either src/bootstrap-amd or src/vs/code/electron-main/main
• We take a quick peek at both files and we can quickly tell that src/bootstrap-amd is used mainly to load src/vs/code/electron-main/main which is the file we're going to be interested in
• Once again, we quickly look around src/vs/code/electron-main/main and find that the main logic is at the bottom of the file
• First the command line arguments are parsed
• Then services are bootstrapped/instantiated
• Finally the CodeApplication is started up
• This leads us to look into src/vs/code/electron-main/app.ts
• As the file is quite large, we start by skimming through it, looking at the available methods on the CodeApplication class as well as its properties
• Looking at the constructor, we can see that a lot of objects are given to it. We also observe the use of the @... syntax (those are decorators)
• In this case (and for most constructors), this is how VS Code does service (dependencies) injection
• One will also notice that most, if not all parameters have a visibility assigned to it. What this does is that it will create an associated property in the class as well as assigning the parameter value to this property in the constructor. Thus, instead of writing


class AnotherClass {
private someClass: SomeClass;

constructor(someClass: SomeClass) {
this.someClass = someClass;
}
}


you simply write


class AnotherClass {
constructor(private someClass: SomeClass) {
}
}

• Upon its creation, the CodeApplication class will register various event listeners on the electron app object
• If we remember, in src/vs/code/electron-main/main, after the CodeApplication object is instantiated, we call startup() on it. So, we want to take a look at what that method does
• Without knowing too much about the VS Code source, it appears that we are instantiating an IPC server (inter-process communication) and then the shared process
• After that is done, we initialize some more services in CodeApplication::initServices, such as the update service (which I guess takes care of checking for VS Code updates) and the telemetry (data about VS Code feature usage)
• We finally get to the point where we're about to open a window in CodeApplication::openFirstWindow!
• This leads us to go read the class WindowsManager in src/vs/code/electron-main/windows.ts. Once again, this file is pretty large, so we want to skim it to see what it contains (functions, classes, properties, methods)
• There are a few large classes in src/vs/code/electron-main/windows.ts that I'd want to extract to make the file smaller and simpler (less cognitive load). However, the issue is that those classes are not declared as exported, and thus are only available in the local file. It would be possible to move these classes to other files and import them, but by doing so it would also "communicate" that others can use it, which is what having the classes as not exported prevents, at the cost of making single files larger and harder to comprehend
• We know that the constructor is first called, then from CodeApplication::openFirstWindow, we see that WindowsManager::ready and WindowsManager::open are both called.
• In the constructor we instantiate the Dialogs class (takes care of open/save dialog windows) and the WorkspacesManager class (takes care of workspace management, such as open/save)
• In ready event listeners are registered
• In open there is a lot of logic associated with the window finally opening

### Notes

• If you start VS Code using the debug feature, you will not be able to open the Chrome DevTools (at this moment, 2018-05-26) because only 1 process is allowed to attach to the Chrome DevTools instance, and that process is the VS Code editor that started the debugged VS Code instance

## 2018-07-08

Today I want to find out how VS Code restores a windows sessions when you start it. Apparently, if you run it as code ., it will not restore the same set of windows than if you called it simply with code.

• In src/vs/code/electron-main/launch.ts, the LaunchService::startOpenWindow appears to implement logic based on how many arguments were given. In all cases, we end up doing a call to the IWindowsMainService::open method.
• Note that in both cases, the path we're opening is within the args variable, which is passed to the cli property of the IOpenConfiguration object.
• The implementation of IWindowsMainService we are interested in lives in src/vs/code/electron-main/windows.ts.
• In the WindowsManager::open method, we rapidly discover that the windows that will be opened will be retrieved in WindowsManager::getPathsToOpen. In there, we can observe that the windows that will be opened depend on whether something was passed from the API, we forced an empty window, we're extracting paths from the cli or we should restore from the previous session.
• If we arrive at this last case, we can see that the logic is to call WindowsManager::doGetWindowsFromLastSession, which is pretty self-explanatory, and will retrieve the previous set of windows from the last session. This is what happens when you start code using code
• In the case where we pass a path, this path is in openConfig.cli._. In this case, the windows that were previously opened, and part of this.windowsState.openedWindows (where this is a WindowsManager object)
• Here we wonder how the windowsState.openedWindows state gets restored on VS Code start. To figure that out, we start at the WindowsManager.constructor method. There we find this.windowsState = this.stateService.getItem<IWindowsState>(WindowsManager.windowsStateStorageKey) || { openedWindows: [] };, which states to use get a IWindowState object from the stateService if one exists or to create an object with no opened windows. If we assume that this windows state is the same regardless of how we start VS Code, then it is not there that the difference in opened windows will occur.
18 May 2018

# Workstack

History / Edit / PDF / EPUB / BIB / 3 min read (~412 words)

The workstack is a very simple idea I had while working. It is based on the concept of a stack as the name clearly implies. As you work, you, like a computer, process things one at a time and as new things need to be done, you either throw them in a todo list (a queue), or you start doing them right away (you stack them).

The workstack is a way to record notes about what you work on. As you work on something, you can either work on them to completion, or be interrupted by the necessity of working on another task. In the first case, tasks are simply written one after the other with their begin and end time. In the second case, items are also indented, such that it is possible to observe when a task forced you to "switch context".

An example of this note taking format is as follow.


2018-05-18


Conceptually, you would want to always complete a stack of operations before moving to a new task. However, it is highly common in programming that a programmer will start going down such stack while working on code and then will not end up climbing back the stack, effectively not completing all he started working on.

This format thus allows a programmer (or anyone working on tasks that can spawn other tasks) to better track what they were doing and what they did and did not complete.

15 Dec 2017

# AI/AGI/ML - A short overview

History / Edit / PDF / EPUB / BIB / 4 min read (~705 words)

After having spent about 200 workdays of my life getting familiar with the fields of AI/AGI/ML, I think it is a good moment for me to reflect back on my learning experience.

## Artificial General Intelligence

Of the three domains, AGI is the least well defined. It has to do with general intelligence, but our definition of intelligence is still up for debate. Furthermore, the different known approaches in the field have different opinions regarding what sort of agent an AGI system should be. Should it be a self-contained entity with its own goals and purpose? Or should it be a system that is exhibiting human capabilities while being the servant of a human being or a group of human beings?

## Artificial Intelligence

Next is AI, which encompasses many different types of approach to try and solve high level goals such as deciding, planning, organizing,, understanding, etc. AI is about the discovery of strategies to solve problems without having to provide the whole solution. I think it is also where goals for the ML field have been defined.

## Machine Learning

Finally, ML is about using statistical approaches to solve problems. These problems have to be formalized and specify their input/output in the shape of data, may it be as text, audio, video, or simply vectors of numbers. Most of the recent and exciting development that has happened in ML is due to deep learning, which is the ability to develop deep neural networks that can learn to accomplish certain tasks without writing any explicit logic. This logic would be discovered by the network itself, with some help of the developer which would define a composition of modules that would process the data in order to create associations between the input and outputs.

## Why AGI?

When I initially started my "adventure", I was interested in AGI. I wanted to know how a machine would be able to exhibit human behavior without having to tell it too much about it. I wanted to learn how you could teach a machine as you would teach a child. The AGI field itself does not currently have any curriculum as to what you should learn about, nor a reference book you can refer yourself or others to (when asked "What should I first read if I want to learn AGI?"). One can be interested in anthropomorphic aspects such as memory, intelligence, perception/senses, processing and so on, while others may be more interested about a computational oriented approach, such as the algorithms, the implementations, the computational complexity of diverse approaches and so on. I think it makes AGI a very interesting topic/field, however it lacks the definiteness of the other fields. One can see this by reading the various iterations of the book "Artificial General Intelligence", which is a collection of articles by various researchers that is generally published every year in relation to its conference.

When I started learning about AGI, I decided I would explore various venues and determine the approaches that matched the most my own interests and which looked the most promising. I looked at different venues such as cognitive science, set theory, logic, universal artificial intelligence, biology, and philosophy amongst others.

Along the road, AGI research has challenged many of my beliefs as well as how I see life. For those two reasons alone, I'm grateful I have been able to dedicate some of my time on it.

08 Dec 2017

# Blog articles vs articles

History / Edit / PDF / EPUB / BIB / 3 min read (~524 words)

One thing I've been wondering about lately is when should one write blog articles (short articles ranging from 250 to 1000 words) or articles (1000+ words) which would be updated (in)frequently but not be as easily consumable.

The main reason I've preferred articles over blog articles is that it makes it possible to keep articles "alive", while once a blog article has been published, it will not evolve over time. By the time it is posted, it is effectively dead and has very little reason to change.

Being a programmer, I've always enjoyed seeing software project evolve over the years. They start small and grow big and complex over time. I like the satisfaction of seeing something grow step by step, and because of that, I've liked the idea of writing about specific topics and seeing these topics and articles change over time.

The problem with articles however is that it is difficult for visitors to consume. Some articles might grow large and complex. Furthermore, it is difficult for visitors to notice any changes from the last time they've come onto the blog.

Another thing is that articles allow the author to "refactor" what he has written, or rewrite/rephrase/reword, such that the article itself improves over time. With a blog article, it is still possible to do so, but the expectation is that a visitor that has already seen the blog article will not re-read it. And here's the important difference between the two: I expect blog articles to be consumed once, but articles to be consumed multiple times. This expectation is likely wrong. The only person that is likely to consume the same article over and over is its author. Visitors may come to the blog many times, but they are unlikely to expect articles to change over time. An extreme example of this idea would be Wikipedia. People will consult the page of the topic they are interested in, but once they've read it, they aren't likely to come back to it again. The only reason they might do so is if they contribute to it.

What this means is that it is still acceptable to improve both blog articles and articles. The difference lies in how we expect our audience to consume each ones. Articles are likely to be seen as references while blog posts are likely to be perceived as an ephemeral observation. One should expect both to be consumed at best once by a visitor, and that the visitor will not come again to see if it has changed.

Thus, in the end, what matters is what we want to communicate with our audience. Do I want to tell you about a thought (a blog article) or do I want to tell you about some information that is likely to evolve over time (an article).

In the case of my machine learning and artificial general intelligence research, what makes sense is to communicate discoveries or shifts in approaches through blog articles while using articles as a location for thoughts to be worked on.

18 Aug 2017