Tell me about your setup

[jdart]

For the past 15 years or so, maybe more, my main dev environment is Linux.

I am using emacs for editing and just running the Makefile to compile, most of the time. My main dev machine is a server that doesn't even have a GUI environment.

I have some custom scripts and tools I have written for running tests across several machines and monitoring the results. Some part of these is public in the Arasan repo, but I have not bothered to document/release/make generally useful all of them.

Once in a while I do development and testing on Windows. That's still mostly emacs + command line but I do bring up the Visual Studio IDE once in a while. I am just not an IDE person though. Too old to learn new ways, and I have all the emacs commands I need memorized, and my fingers just go there automatically.

[abulmo2]

I develop on Fedora Linux. I use gedit as an editor, D-lang compilers (ldc2 mostly) , makefile for compilation, gdb for debugging, perf for performance monitoring, git to publish on github and a few other tools.
I have developed my own command line tools to test my chess programs (or any uci chess engine):
- epdtest to rapidly test progress (or more accurately big regression) on epd files (list of chess problems ).
- tourney to run head to head matches using the pentanomial model of SPRT.
- postmortem to analyze games.
I use xboard, cutechess and some other gui to test my program.

I also gracefully thank people that send bug reports to me. It helps me to enhance the correctness of my programs.
I am also in debt to people who run my chess engines on CCRL, CGET, etc.

[smatovic]

https://talkchess.com/forum3/viewtopic. ... 29#p919730

All my OpenCL stuff was done with Ubuntu Linux, Intel, AMD and Nvidia devices are well supported, I like the toolchain, gcc, clang and mingw crosscompiler are fine for me, and you can easily deploy into the cloud, still need a Windows partition on my workstation to test the OpenCL stack and GUIs, I guess at some point virtual machines will also be able loop through the gpu device, saw recently an article about macOS in a VirtualBox, in future a single host might be enough to cover all OS, or alike.

+ gedit, vi, make, Ruby for epd scripts, CodeXL, NSight, online compile explorer, AMD profiler, Linux perf tools, XBoard mainly.

--
Srdja

[jtwright]

I develop on Arch Linux. Emacs as my primary text editor. Tools like perf for performance stuff, cargo/rustc for building, and cutechess/cutechess-cli for playing/strength-testing.

In terms of more custom stuff, I use tissa-trainer and Endian, which are (somewhat janky) tools I made to aid development. Tissa-trainer is my NNUE training code, derived originally from zahak-trainer, though having deviated since. Endian is basically a Python program that serves as a suite of sometimes niche engine testing features, like testing engines on suites of puzzles, generating random opening positions (for training), etc. It's not really polished enough for general use though. Lastly I have an SPSA tuner Python script I've written as well, though it is bespoke to Mantissa. It doesn't have a cool name though.

When trying stuff out with the engine, I usually run it from the command line and just type back and forth into the UCI interface, though I have also made use of lichess's new ability to use external engines in the analysis board (https://github.com/lichess-org/external-engine if you're interested). Some lines, etc. are easier to explore with Mantissa through an interface like that than on the command line. Admittedly though, I have over time become pretty fast at typing FEN strings by hand while staring at a chessboard.

[algerbrex]

I usually do all of my coding in VS Code. Blunder's written in Golang, so I mostly utilize the ecosystem around it. In particular, the profiling capabilities Go provides is incredibly useful and easy to get up and running.

For testing I like cutechess a lot, both the GUI and CLI. I generally do all of my testing at a 10+0.1s time control, unless it's something that I think might require a higher depth to be properly tested, like a certain search modification.

My usual process looks consists of doing some brainstorming on an area I think Blunder could be improved. I then might do a little research either on the CPW or here. Then I'll write up a basic first draft and start playing around with it. Once I feel I have something good I'll create a new branch to save my work, and then start running a test of 8000 games. Usually within the first 4000 games I can tell if an idea is a complete wash so I can save time here.

If the idea passes testing, I might do a couple more tweaks to see if I can find any improvement. Then I'll merge the branch into the dev branch and upload the changes to the remote dev branch.

I do use some dirty Python scripts sometimes for different utilities, like creating new tuning sets. One script I've actually added into the Blunder repository uses output from the tuner to generate a graph of the error rate through tuning. It's a nice sanity check to make sure the tuning is actually going as expected and the error rate isn't just bouncing around aimlessly.

Beyond that I've added some useful tools to Blunder as command line options that I've started using myself. One tool runs the tuner, one generates training sets from PGNS, and one that generates fresh magic numbers. Hopefully this will also be useful to others. They can be tried out by compiling the dev branch: https://github.com/algerbrex/blunder/tree/develop, and they'll be part of the next official release binaries, whenever that happens.

[expositor]

• neovim for editing (in konsole on arch linux)
• compiler explorer for examining rustc / llvm output
• perf for recording where Expositor spends her time [1]
• expositor's built-in trainer for training neural networks
• cutechess-cli for self-play testing
• whole bunch of custom ruby scripts for doing data analysis, spsa tuning, &c

Expositor has several built-in tools ("show", "eval", "trace", "stat", support for short algebraic notation, support for pgn, ...) that make her really easy to work with on the command line, but since Lichess offered beta support for external engines, I use Lichess as often as not.

[1] You can also get detailed annotations, which are often very helpful, but can sometimes be difficult to interpret.

[chrisw]

It changes depending. Own space and no distractions. Un-interruptible power supply units. Reliable test and development partner (2+2=5). Right now Win10 and VS2022 (been using VS since MS first sent out its precursor in beta form in 1997). C++ for chess engine. PyTorch with handwritten C++ for NN training. Multiple Python scripts for handling pgn and fen. Cutechess CLI is useful and there are various GitHub tuners. I can train four different nets at once, 2x3090 and 2x2080. Two 6 core intels mostly used for training, and two 64 core AMDs mostly for testing and tuning. Several 2T SSDs. If you want to do this seriously you need a lot of kit, I could do with plenty more cores and way faster internet. Starlink just dropped their price to euros 50 per month in France (was 110), so looking at that.

[Mergi]

Gedits and notepads?! How do you people do it? I'm just a bit sad nobody mentioned Clion yet. I switch a lot between linux and windows for development, but i'm a lazy person and Clion works on both out of the box just the same without requiring any extra setup. I used to work with VS code a little bit, but i just didn't have the patience to set it up properly to make it feel like a real IDE.

[dangi12012]

Win 11 + Visual Studio + Visual Studio Code + compiler explorer + Windows Subsystem for Linux (Ubuntu)
There is literally nothing I would miss and I feel this is the pinnacle of convenience for C++

Especially VS Intellisense is miles ahead of other IDEs for C++.

[op12no2]

A simple folding editor I wrote about 20 years ago, Google Chrome for debugging and Node.js for tuning/testing. (Javascript engine.)

https://op12no2.github.io/lozza-ui/