All the good FOSS vibes, without any of the hard FOSS work...
These repo's will usually have half a dozen or more Microsoft Employees with "Project Manager" titles and the like - extremely "top heavy". All development, decision making, roadmap and more are done behind closed doors. PR's go dormant for months or years... Issues get some sort of cursory "thanks for the input" response from a PM... then crickets.
I'm not arguing all open source needs to be a community and accept contributions. But let's be honest - this is deliberate on Microsoft's part. They want the "good vibes" of being open source friendly - but corporate Microsoft still isn't ready to embrace open source. ie, it's fake open source.
Not sure for VSCode, but for .NET 9 they claim: "There were over 26,000 contributions from over 9,000 community members! "
I'm no fan of Microsoft but that's a massive maintenance burden. They must have multiple people working on this full time.
gh pr list --repo microsoft/vscode --state merged --limit 1000 --json author,mergedAt,title
Then you can do:
jq -r '.[] | [.author.login, .author.name] | @tsv' 1kprs.json | sort | uniq -c | sort -nr
And see there's only 63 authors and > 90% of the merged PRs are from Microsoft (which.. fair, it's their product).
I think the signal is strong enough that you can legitimately reach the same conclusion by mk 1 eyeball.
NOTE: I'm not criticising, it's a Microsoft-driven project and I am fine with that. The _do_ merge things from "random" contributors (yay) but they are overwhelmingly things that a) fix a bug while b) being less than 5 lines of code. If that is your desired contribution then things will go well for you and arguably they do well at accepting such. But they are very unlikely to accept a complex or interesting new feature from an outsider. All of this is seems totally reasonable and expected.
Of course the majority are from Microsoft, they do seem to merge in a fair amount of PRs from the community though.
I get it might not be perfect, but "nonsensical mess" is maybe in bad faith here.
Historically, setting syntax colors has sucked too, but I don't remember the current state of that.
https://github.com/microsoft/vscode/pulls?q=is%3Apr+is%3Aclo...
I don't think it's well-aimed criticism to say that the LLM design/training material itself should have been made open source. Pretty much no one in the open source community would have the computational resources to actually do anything with this...
I don't understand this criticism.
The criticism is that most of the value is (presumably) on the API service side.
Of course most of the value is on the API service side. That holds true for most applications these days.
In the end, the fact that it exists makes a difference. It won't be useful to all especially non-technical people who've never seen the nuts and bolts of a vscode extension.
"Copilot chat" isn't open source. It's the service.
As has always been the case, it's the mechanisms used to feed relevant contextual information and process results that sets one tool apart from another. Everyone can code up a small agent that calls in LLM in a loop and passes in file contents. As I'm sure you've noticed, this alone does not make for a good coding agent.
I have had what appears to be the same, or similar, complaint against "Web APIs" for many years when trying to access public iinformation. Not that long ago, websites did not have "APIs". Generally, I still extract information from the public websites rather than use "APIs". This requires no sign up and is guaranteed to work as long as the website exists.
Before "Web APIs", websites did not routinely collect email addresses, track usage, rate limit individuals and charge subscription fees in exchange for access to public information.
Sometimes the "Web APIs" are free but "sign up" is always required. There is email address collection, usage is tracked, "accounts" are rate limited. In the past, some HN commenters also complained that these "APIs" are unreliable in the sense that they can be "discontinued" suddenly for any reason. Anyone depending on them has no recourse.
These "Web APIs" became so common that their rationale went unquestioned. For example, why not let www users download bulk data. In rare cases, this is an option, e.g., some government websites, Wikipedia dumps, etc. But this is the exception not the norm.
In light of these comments complaining about accessing LLMs through Web APIs I am wondering:
Are "Web APIs", "SaaS", etc. now being turned against the people who concertedly promoted these tactics, namely, software developers.
I always saw "APIs" as an easy way website operators could deny access to www users. Like some requirement to have an "account" in order to access public information. Those providing these "APIs" have the data in a format they could provide for download, e.g., JSON, but bulk downloads are not provided. This tactic of charging fees is quite different from how websites operated for the first decades I used the www.
Similarly, LLM providers have details about the models, e.g., weights, etc., in formats they could provide for download. Instead, users are encouraged to "sign up", "subscribe", or whatever, for access to public information^1 through an "API".
1. Assuming the provider obtained the training material from the www, a public resource.
I was not aware that was a thing and useful to know. Thanks!
Have you even used any of their products lately? Where "lately" = the last 15 years...
Also it's all Microsoft, they made both the AI and the editor. I appreciate that they don't do anything extra in the editor to favor their own extensions.
hu3•7mo ago
dataviz1000•7mo ago
1. User selects ask or edit and AskAgentIntent.handleRequest or EditAgentIntent.handleRequest is called on character return.
2. DefaultIntentRequestHandler.getResult() -> createInstance(AskAgentIntentInvocation) -> getResult -> intent.invoke -> runWithToolCalling(intentInvocation) -> createInstance(DefaultToolCallingLoop) -> loop.onDidReceiveResponse -> emit _onDidReceiveResponse -> loop.run(this.stream, pauseCtrl) -> runOne() -> getAvailableTools -> createPromptContext -> buildPrompt2 -> buildPrompt -> [somewhere in here the correct tool gets called] -> responseProcessor.processResponse -> doProcessResponse -> applyDelta ->
[0] https://github.com/microsoft/vscode-copilot-chat/blob/main/s...
[1] https://github.com/microsoft/vscode-copilot-chat/blob/main/s...
[2] src/extension/intents/node/toolCallingLoop.ts
_boffin_•7mo ago
dataviz1000•7mo ago
All I can find is counting number of tokens and trimming to make sure the current turn conversation fits. I can not find any chunking logic to make multiple requests. This logic exists in the classes that extend IIntentInvocation which as buildPrompt() method.
_boffin_•7mo ago
will update when i find more info.
chatmasta•7mo ago
I haven’t really thought about it beyond “JSX is a templating language and templating helps with prompt building and declarative is better than spaghetti code like LangChain.” But there’s probably some kernel of coolness there.
sqs•7mo ago
dataviz1000•7mo ago
They also provide documentation for all this. [1]
VSCode also provides examples. [2]
[0] https://github.com/microsoft/vscode-prompt-tsx
[1] https://code.visualstudio.com/api/extension-guides/chat
[2] https://github.com/microsoft/vscode-extension-samples/blob/m...
rightbyte•7mo ago
> in a minute
Honestly. Why the hurry?