That's not that kind of jump the OP is talking about. dumb-jump/anyjump are plugins which allow you to jump to definition / declaration etc. without having any kind of language server running or having preprocessed the source code. They work by essentially grepping through the source code on the fly with some language specific smartness on top to make it work better.
Interesting approach. But for me the main disadvantage of SQL code embedded in other language is lack of syntax highlighting/checking.
I've had the best experience with embrace-sql which translates sql-files with magic comment-delimited parametrized queries to python-callable modules: https://pypi.org/project/embrace/
I wish there was a way to get around the syntax highlighting, checking, and completion issue. Pandas has a nice `query` method, which is hard to use for the same reason.
I think that the ultimate result (sqlite-wasm) is better than what Web SQL database could provide. Today you can bundle your own version with your own set of native extensions. In case of standard Web SQL you would be forced to check the version and figure out, is it finally possible to use RETURNING in queries.
Two years ago I moved back to paper for my productivity and notetaking after about 7 years going fully digital. There are a lot of advantages for me. Some of those may apply to others:
- Tactile feeling and aesthetics. My writing is not very beautiful, but a stack of papers filled with my notes and diagrams is very inspiring.
- Paper is an offline, distraction-free medium. I think better with paper. Maybe it is a cultural habit.
- Paper won't disappear one day due to bad battery, untested OS update, malware, EOL for cloud service etc. Losing a couple of sheets of paper is easier than electronic device. But when speaking about losing a bulk of notes, it is much easier to lose it electronically than physically.
- Paper is forgiving. I can draw quick-and-dirty diagram in a minute and move on. It is hard to draw quick-and-dirty diagram on a computer. I will spend at least a couple of minutes deciding which app will be more convenient to draw this diagram, about ten minutes fighting an app, and up to an hour fighting my perfectionism, placing all shapes in proper places in grid.
- A sheet of paper is bounded, which helps with internal distractions. If I need to make a TODO list, I will take a smaller sheet, and fit all important things there.
- When you have large desk, you can spread a lot of paper sheets on it and see it all at the same time. Rearrange it, put it in stacks by some criterion, and so on. And neither scrolling nor list of thumbnails work as good as flipping through a paper book.
Disadvantages are:
- Lack of search function. I didn't try Apple Notes document scanning recently, maybe some kind of handwriting recognition is there and it will be enough to just take photos of all my notes.
- Portability: I need a desk with enough free space for both laptop and papers (so, mostly in terms of depth - probably a problem for open space offices).
I have some hopes for Apple Vision Pro (maybe in V2 or V3). I think it has a potential to bring some of these advantages to digital world :)
It is yes, they've even built a command for it "rebuild"[0]
> Reconstruct the named repository database from the core records. Run this command after updating the fossil executable in a way that changes the database schema.
Afaik fossil just uses sqlite under the hood to store metadata. It would surprise me sqlite doesnt stash min and max required versions and refuse to work outside of those bounds
It does do exactly that. If you visit https://sqlite.org/src/stat, the "Schema Version" line tells you exactly what version of the database schema that the repository is using. The SQLite repository uses the very latest Fossil schema, which you can see from the "stat" page has not changed in 8.5 years.
> git, for all its issues, is not bundling the kitchen sink.
It doesn't bundle the kitchen sink in its native *nix environment, but for Windows it does. Git installer is > 50 MB, including (if I remember correctly) even a terminal.
While you can download Fossil as a 3.3 MB standalone binary for any supported platform.
Let's not forget how long it even took for there to be a reasonable Windows build of git. Git implicitly relied on significant amounts of Linux tooling which required bringing over an entire Mingw environment.
Actually I do to save me from the deprived interfaces the OS ships with.
The Git install is one of the best Cygwin-likes I've encountered. It has the majority of tools needed and reasonable integration with the host OS. Very nice for getting something done quickly on any random Windows box.
It's fine if you don't have anything else installed already, but I have MSYS2 installed so it'd be nice if it were optional. Realistically an extra 50mb is not going to materially affect my life, but it's still aesthetically displeasing.
I agree - that's why I use the git package in MSYS2, which afaik is just as capable (and makes it much easier to use git with the full array of UNIX tools I might want to use that don't necessarily ship with Git for Windows).
I remember people installing git-bash and putty for Windows in computer science class to fill in all the gaps. Idk what the deal was with that cause, uh, why would I use Windows.
Actually it does, because with the windows git it includes it's own copy of ssh and bash, both of which will clash and fight with msys and/or other ssh installs - including the copy of ssh that microsoft themselves tuck away in \windows\system32
it's quite 'normal' for git-for-windows' ssh-agent to completely disable ssh-agent from working properly system-wide because it ends up pointing things at the wrong ssh-agent.
Pretty much all game development still happens on Windows because that's where all (or at least most of) the gamedev tools and middleware libraries are.
That's a pretty ignorant view, there's tons of developers using Windows. If you take a look at the SO survey (or similar ones), Windows has 47% in the "Professional use" category.
13B uses about 9GB on my MacBook Air. If you have another machine (x86) with enough RAM to convert the original LLaMA representation to GGML, you can give it a try. But quantization step must be done on MacBook.
Maybe it is more feasible for you to use 7B with larger context. For some "autocompletion" experiments with Python code I had to extend context to 2048 tokens (+1-1.5GB).
Maybe it's me personally, but with M1 / M2 Macs the quality of a product (hardware + software) is far ahead of anything I could get with GNU/Linux, unfortunately. macOS quality isn't as great as it was, but (from my most recent "coming home to M1 Mac" after 4 years on GNU/Linux) sound settings with various configurations including microphones, AirPods, external and internal speakers do work, and OS "automagically" remembers settings for each combination. External displays with different DPI just work (and, again OS does remember all display settings). AirDrop and AirPlay, Keychain and Notes sync (with OCR search) etc just work, not even speaking about famous Mac "instant DHCP". And, as a bonus, kernel upgrades don't randomly break GPU or WiFi drivers.
So, it's really great it works for you, but, sadly, for me a lot of things on macOS "just work", both essential and unessential, while in GNU/Linux many essential things "just won't work", even considering its much better developer experience.
However, these 100 LOC probably could be split into an internal library function which won't change until necessary. If you use an external library (especially in JS and especially in frontend), you or your successor will have to update all these 5 LOC entries all over the code every 1-1.5 years in a non-trivial way when a new major version arrives.
That's why you can use fixed library versions to make sure nothing changes. If you need to update something in the library, you can apply a patch and keep going.
On Linux I used Astroid for offline mail access (notmuch + lieer for gmail and mbsync, I think, for other mailboxes - it worked so good that I don’t remember exactly). For me it is the best offline email setup.
On macOS, unfortunately, I haven’t found anything better than Apple Mail, considering the integration with OS. There are downsides, though. Offline format is incompatible with everything else, it’s hard to do rsync backups of ~/Library/Mail, and I don’t think all mail is accessible offline. It is slow, and it mangled non-latin attachment names for Gmail letters. On positive side, there is a great support for drag&drop, Spotlight integration, multiple account handling.
- lack of global search (like ripgrep integration) and something like dumb-jump/anyjump — it's faster and less resource-intensive than running LSP
- I encountered a couple of panics losing my unsaved changes after 24.03 update, most recently yesterday. Looks related to this bug: https://github.com/helix-editor/helix/issues/3501
I can live with no global search, but not with data loss. Probably will stop using it for now.