TBH, no criticism on the developers, but the VS Code release notes haven't been interesting or relevant to how I used the editor for years. I think I checked out when they added a terminal client to it and it dominated the release notes for ages.
AI features is one of the bigger innovations in editors in years, I fully understand the enthusiasm, especially given it can be linked to an earnings model. That said, before AI stuff I would've expected them to push integration with Github and Azure more.
Well, I used Emacs for 15-20 years. It has problems of its own -- mostly that it is effectively locked into an antediluvian view of how editors work, and that to use it effectively you end up maintaining large and complex configuration files.
I still use it for some things, but what we really need is a new, different edition of Emacs that has the same basic architecture but a more modern take on all the stuff that dates from the 1980s.
It's not "a problem," it's a difference in philosophy. Sure, VSCode comes accessible out of the box with minimal configuration needed and a GUI-first settings interface. But that comes with its own price - your config is more restricted in what you can do and fragmented across json files, settings menus, and extension options.
In contrast, with Emacs I can change any behavior of any function and command - built-in or third-party with amazing granularity. I can change specific parts of a function without rewriting it, and I don't even need to save that - I can just write a piece of Elisp in a scratch buffer, evaluate it, and test it out immediately.
Also, you are completely wrong with your notion that Emacs is outdated. Modern Emacs tools allow you to do things in a way no other editors let you - you can control video playback, read and annotate PDFs, search through your browser history, and automate things with LLMs.
Not to mention that the problem similar to the one being discussed in the thread would never happen in the Emacs world - nobody would ever get to publish a package with obfuscated Elisp code in it. You always will have full control over the code you download to use.
git uses "plumbing" and "porcelain" commands, referring to victorian-era plumbing systems. Adobe and other publishing tools use terms like "slug", "gutter", "folio", "pica". Debugging tools use terms like "trap", "dump", "patch". You're annoyed with what Emacs calls "window" and "frame"? And what about Tmux's "pane" and "window"; or "session" - "an ancient" term from the time of timesharing systems? Oh boy, if you afraid of words don't ever try to get into Haskell - those FP-crazies do use some real fancy words for their stuff.
> knowledge of Elisp, which has zero other benefits
The same way the knowledge of sql, or awk, or bash, or vim motions, or ssh, or tmux has zero benefits outside of their respective domains? What are you even talking about? I, for one, get daily gains, benefiting from knowing elisp - anything that has to do with text, just about anything can be automated with ease.
Just the other day - watching my colleague over Zoom, I decided to fix that for my note-taking. It took me fifteen minutes to write a piece of Elisp that OCRs any piece of text from a screenshot. Instead of disrupting my teammates all the time, I would now take a screenshot of a screen area with Flameshot, run my custom command and voilà - the text appears in my editor, and I can quickly grab it and use it in my notes.
I don't know where exactly "you've been" and what "you've done", but it really sounds like you haven't seen modern Emacs in practice. When one sees what people can do these days in it, it's hard not to get impressed.
XEmacs Tried to do that, it has been attempted to rewrite the backend of emacs into Rust twice, Guile has tried to interpret emacs lisp twice. The biggest problem is basically how large the user base is and the ability of people to want to perform the port so actually improving the editor is more likely.
GTK+ and webkit has been integrated into emacs and it has a package manager now and configuration is still a problem.
this is not about who they vote for, it's the system that is neoliberal in that allows and incentivizes only maximum profit and puts very little barriers
Makes me wonder if "I don't know" could be added to LLM: whenever an activation has no clear winner value (layman here), couldn't this indicate low response quality?
Generally speaking, AI Engine processors are in-order, exposed-pipeline VLIW processors. Each VLIW instruction bundle specifies the behavior of one or more functional units,
which begin executing a new instruction at the same time. The processor pipeline does not include stall logic to enforce data dependencies, and instructions will continue
executing in order regardless of other instructions in the pipeline. As a result, the compiler is able to schedule machine instructions which access the same register in ways that potentially overlap
So a software scheduler? I had no idea it works like this. Very interesting.
If you've taken a compilers course, it's pretty similar to register allocation. You want to make sure you're using as much of the processor as possible.
Just open the drop-down to select the C++ standard. Below, there is a section "More Transformations". Enable "Show coroutine transformation", and you will get the transformation you're looking for: https://cppinsights.io/s/4d8c3fc1
This isn’t about passwords. The token from the identity server (Google in this case), describes the user, including their identity - which you may use as a link to the user data. If I were to forge an token, I could impersonate the user. For this reason, you need to verify the token with the identity server.
I'm wondering how AI scientists work these days. Do they really hack Cudakernels or do they plug models together with highlevel toolkits like pytorch?
Considering its the latter, considering pytorch takes care of providing optimized backends for various hardwares, how big of a moat is Cuda then really?
I guess Copilot functionality trumps "Security above all else" now.
https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...