GSOC 2026 Project #4 : Brian Simulator - Complete/finalize code editor support for Brian model equations (175h)

GSoC
1

Differential equations, defined in Python strings, are at the core of Brian’s model descriptions. They use a language familiar to computational neuroscientists, and closely follow the way that languages are described in scientific articles. Defining these equations in strings has the advantage that these descriptions are very concise, and can be read as mathematical equations, and not as programming code. The fact that equations are “just strings” does have disadvantages as well, though: from the point of view of a code editor, they are simply text and do not benefit from helpful features such as syntax highlighting, autocompletion, or syntax checks.

To improve this situation, a former GSoC student implemented g a Brian-specific “Language Server extension” and syntax highlighting rules, that provides these features for Brian equations embedded in a Python script. The Language Server Protocol (LSP) has been created by Microsoft and is used to provide advanced editing features to editors such as Visual Studio Code, but it is now supported by a large number of editors.

The goal of this project is to complete the work on the existing proof-of-concept and make it production-ready. In particular:

  • Make the installation progress smooth and integrate with VS Code’s existing Python support
  • Implement a smart and robust detection of equation strings
  • Implement semantic autocompletion
  • Implement helpful error displays inside an equation string
  • If time permits: add support for automatic formatting of equations

Skill level: intermediate

Required skills: JavaScript/TypeScript, JSON, asynchronous programming, basic knowledge of grammars/regular expressions.

Lead mentor: Benjamin Evans (B.D.Evans@sussex.ac.uk)

Project website: GitHub - brian-team/brian2: Brian is a free, open source simulator for spiking neural networks. · GitHub and GitHub - brian-team/brian-code-editor: GSoC 2023 project: Code editor support for Brian model equations · GitHub

Backup mentors: Marcel Stimberg (marcel.stimberg@sorbonne-universite.fr; mstimberg on NeuroStars) , Dan Goodman (d.goodman@imperial.ac.uk; d.goodman on NeuroStars)

Tech keywords: Python, Visual Studio Code, Language Server Protocol

2

@emollier @mstimberg I did a quick deep dive into the traceback of test_active_flag.

It seems the crash Fatal Python error: Aborted is happening inside the Cython runtime (cython_rt.py) during run_block. This suggests that on Python 3.13, the interaction between the generated C++ code and the new Python C-API might be causing a memory or thread-handling conflict (possibly related to the new Tier 2 optimizer or changes in garbage collection).

I’m currently:

  1. Isolating whether this happens only with the Cython device or also with the Runtime device.
  2. Checking if the Fatal Python error is linked to how execnet handles workers in Python 3.13.

If anyone else is seeing this, are you on a specific architecture? I’m trying to reproduce the exact ‘Aborted’ state on my environment now to provide a proper fix.

3

Hi @pradeeep-pal I think this was meant to be posted into the GitHub issue: test failures "Fatal Python error: Aborted" · Issue #1777 · brian-team/brian2 · GitHub

4

Hi @mstimberg ,

I’m exploring the Brian code editor for GSoC and had a question regarding the syntax highlighting for NeuronGroup and Synapses definitions.

Here’s the related GitHub issue for context: [Extend features to `NeuronGroup` and `Synapses` definitions · Issue #11 · brian-team/brian-code-editor · GitHub]

Just wanted to share it here as well in case this is a better place for discussion.

5

Hi @Mohamed-Sobea. Here is a good place for general discussions, more specific ones are always welcome in the related GitHub issue (I just replied over there).

6

Hi everyone, I’ve written up some general recommendations for GSoC applications on our website: GSoC 2026 | The Brian spiking neural network simulator

Regarding this specific project, the most important first step would be to get the existing extension running locally on your system (i.e., not just the package from the VS code marketplace), so that you are ready for development. Implement a (small!) feature or fix a bug in your local version, and show (with a screenshot) what the change looks like for the user. Ideas for features/bugs: make the autocomplete more specific (it currently proposes units and flags together); syntax highlight function calls in equations. Regarding the features that we want to implement during the GSoC: describe in detail how they would look like (from the user’s point of view), and where these features would be implemented (in the server.py, in extension.ts, in the language syntax description, somewhere else?).

Obviously, please do not hesitate to ask in case anything is unclear.

1 Like
7

Hi @mstimberg, thank you for putting together these recommendations.

I’ve actually just gone through these steps and opened PR #12 on GitHub for Issue #11. I included the screenshot of the local development host there as well.

8

Hi @mstimberg , I’ve just cloned the repository and am currently exploring the codebase. I’ll get back to the discussion if I run into any issues. Thanks for recommendations for GSoC

9

hi @mstimberg ,

I’ve gone through the repository and have already raised a few PRs and issues on the official repo. I’ve also prepared a proposal based on my understanding of the project.

Would it be okay if I share my proposal here in the discussion thread to get some feedback and suggestions? I’d really appreciate any guidance to help improve it.

I also had a couple of technical questions while exploring the codebase:

  1. I noticed that during development, the language server is exposed over a TCP port instead of using stdin/stdout. Could you please explain the reasoning behind this choice? Is it mainly for easier debugging or flexibility?

  2. After exposing the language server over TCP, what is the recommended testing strategy for validating LSP features ? Are there automated approaches/tools that the project prefers?

10

also, if I am correct do we have to pipe error from this output or there is any better way of validating a brian equation.

Screenshot 2026-03-23 at 5.23.48 PM
Screenshot 2026-03-23 at 5.23.48 PM2880×1102 312 KB

11

Hi @Anshik_Singh

For the actual proposal, I prefer a link over direct message (as you already did) – otherwise, uploading it to the GSoC platform works as well.

I don’t remember we actively made that choice back in the days – maybe it wasn’t supported by pyglsback then? Or it was simply what the example we based our code on used? If there is an advantage of switching to the stdin/stdout system, I wouldn’t mind either.

This is the first and so far only LSP project I worked on, so I don’t actually know what the best framework for testing is these days. Back in the days, we only manually verified the output in example files, IIRC.

If by “pipe error” you mean try/except, yes, that’s the best we can do for now (see brian-code-editor/brianextension/server/server.py at 44bdaeb495dd15d41381260ff4a2c4c31d51ed08 · brian-team/brian-code-editor · GitHub ). There are various ways to improve on this, e.g. SyntaxError contains more detailed information about the position where the error occurs, and we could also try parsing each of the equations independently, to only highlight the failing ones for example. I don’t know if we can hook into the default Python extension somehow to get a list of defined names (variables, etc.), if yes, we could do also highlight unknown names in the equations.