I’m writing a language server for Csound and I’ve been removing pieces of code here and there to check which errors Csound throws. I’ve found three main error types that I’ve already included in my unit tests but I’d love to hear from the community if there are more I should put in my list.
Yeah! I’m collecting Csound error outputs for a good cause
type one:
Compiling Csound code...
error: unable to find opcode with name: aOut, line 21
SEMERR: unable to find opcode with name: aOut, line 21
Parsing failed due to syntax errors
type two:
error: syntax error, unexpected NEWLINE (token "
")
from file synth.csd (1)
line 12:
>>> <<<
No number following instr
type three:
error: Variable type for Amp could not be determined, line 21
SEMERR: Variable type for Amp could not be determined, line 21
from file synth.csd (1)
The syntax errors are the most consistent ones but sadly for others they aren’t structured. I would have LLM read over csound repo to give you this answer.
Sorry about my late reply! I just had the chance to right a bit of a long answer to your questions:
This is the first time I’m writing an language server as part of the beginning of the path I finally started liking developer experience field after exploring my careers options for a while. The language server is in Go and if I can make it, I’d love to continue with a tree sitter, a formatter and a linter… let’s see how far I can go with this project series. The main reason for doing this on my own is to give back to the internet since I’ve mainly learned how to code on my own with multiple open source resources.
Based on my recent learning process in developer experience, I think the compiler could have a more standardized way to log error that could help CSound coders understand what goes wrong ideally in one line of code that fits any code editor window ideally. On the other hand having a standardized error logging helps with designing regex pattern that easily match the error line number aside the error message and the conflicting piece of code to get the position from so the language server can position the course on that bit of code. In my opinion the following existing error format work perfectly fine except for the colon before the variable that causes the error:
error: <description> <opcode/code> <line number>
This could be cleaner in my. No colon, no semicolon
Now, I could see that the compiler reports on error at a time so I was wondering if reporting all error at the same time could improve the developer experience cause coders can feedback of all errors to fix instead of feeling hopeful with one error and then disappointed because there were unreported related errors that popped up one by one.
This is my input for now and I’m open for discussion. I feel this could be a great opportunity to learn from you guys about how you design CSound to enable musicians/sound artists/coders to make some noise
I went over these error messages a while back to try to create some bit of consistency. But it’s not enough. @hlolli is right about this being a good use of an LLM. Btw, are familiar with GitHub - PasqualeMainolfi/csound-lsp: Csound LSP · GitHub? Seems you might be working towards the same goal?
Hi! That’s alright, I’ve found three types of errors so far, I might find more on the way but I wanted to survey the community in case some experts would add more types of error I should take care of.
Yeah! I saw Pascual’s work in Rust. In my case though, this is my first sort of DevX portfolio project that includes not just the language server but also interacting with the community to understand its needs and get its feedback. That’s part of the developer experience engineer role so why not doing that from day one
Question: How did you design the compiler output? Did you follow some criteria for doing that?
Can I try to improve them as a contribution to CSound? I’d like to take a look at the source code to see if I can add consistency after doing a bit of research on best practices. We can dm each other with details if you want
