It is a well-known “fact”, in some circles, that running grep in the C locale is much faster than in UTF-8 locales, the latter being a common default on current client systems.
Indeed, just the other day, a colleague of mine was running something akin to:
grep ‘“event-type-id”:4727’ app.log
app.logis a multi-gigabyte file of JSON lines1, the goal being to quickly see whether a newly-added type of event is seen. Almost immediately, someone jumped in to recommend running grep in the C locale, instead of the default UTF-8 locale, for Guaranteed Extra Speediness™.
I wondered whether this was indeed good advice. (TL;DR: using the C locale does not help performance in general, or jump to conclusions.)
Alf is a modern, powerful implementation of relational algebra. It brings relational algebra where you don’t necessarily expect it: in shell, in scripting and for building complex software. Alf has an rich set of features. Among them, it allows you to:
Query .json, .csv, .yaml files and convert from one format to the other with ease,
Query SQL databases with a sounder and more powerful query language than SQL itself,
Export structured and so-called “semi-structured” query results in various exchange formats,
Query multiple data sources as if they were one and only one database,
Create database viewpoints (mostly read-only viewpoints for now), to provide your users with a true database interface while keeping them away from data they may not have access to,
Enjoy a rich set of relational operators and even define your own high-level and domain-specific ones.
Neorg is a tool designed to reimagine organization as you know it. Neo - new, org - organization. Grab some coffee, start writing some notes, let your editor handle the rest.
Why do we need Neorg? There are currently projects designed to clone org-mode from emacs, what is the goal of this project? Whilst those projects are amazing, it’s simply not enough. We need our own, better solution - one that will surpass every other text editor. One that will give you all the bragging rights for using Neovim. Here’s how we’ll do it:
Revise the org format - Simple, very extensible, unambiguous. Will make you feel right at home. Org and markdown have several flaws, but the most notable one is the requirement for complex parsers. I really advise educating yourself on just how bad markdown can get at times; what if we told you it’s possible to eliminate those problems completely, all whilst keeping that familiar markdown feel?
Enter the .norg file format, whose base spec is almost complete. The cross between all the best things from org and the best things from markdown, revised and merged into one.
Keybinds that make sense - vim’s keybind philosophy is unlike any other, and we want to keep that vibe. Keys form a “language”, one that you can speak, not one that you need to learn off by heart.
Infinite extensibility - no, that isn’t a hyperbole. We mean it. Neorg is built upon an insanely modular and configurable backend - keep what you need, throw away what you don’t care about. Use the defaults or change ‘em. You are in control of what code runs and what code doesn’t run.
Logic. Everything has a reason, everything has logical meaning. If there’s a feature, it’s there because it’s necessary, not because two people asked for it.
Everyone 1 and their dog 2 loves Git. I know I do. It works, it’s efficient, it has a brilliant data model, and it sports every feature under the sun. In 13 years of using it, I’ve never found myself needing a feature it didn’t have. Until recently.
But before I tell you about it, let’s talk about GitHub.
Even in the age of smartphones I still prefer to check the calendar on my computer and I’ve often been disappointed by the horrible default calendars that ship with some operating systems (e.g. macOS’s calendar accessible via its systray).
Fortunately for us, Emacs users, we always have access to a proper calendar regardless of our OS and desktop environment (if any) -
M-x calendar. By default it looks something like this:
A post-modern text editor.
While discussing with fellow developers, I was asked the following question a few times: We spend most of our time as developers thinking, not editing code; so, why invest time into mastering a complicated code editor, and why lose some cognitive resources on thinking about text editing instead of about the real programming problem?
I think this point of view is misguided, for a few reasons:
Despite their name, code editors are not only about editing, but also about code navigation. Programming is a hard task partly due to the huge amount of context we have to keep in mind, and being able to quickly navigate code helps us refresh that context, by looking at definitions, implementations, and comments.
Although code editing itself is not the most important part of programming, it still takes non-negligible time to perform, and can be optimized by using better tools.
Finally, a programming career spans a few decades, so investing a few weeks to improving our editing and navigating speed is definitely worth it.
I have heard about Neovim for a long time. I can say that I really appreciate and adopt the ideas of Neovim – it’s more progressive, embraces open source community, and tries to make Neovim approachable to more developers.
However, for its functionality, I didn’t see much difference between Vim. There are various reasons. Firstly, Neovim is a drop-in Vim, so even the plugins could compat each other without much modification, if it is not implemented with Vim or Neovim specific feature. And Neovim somehow pushes Vim to evolve and release similar improvement. e.g., asynchronous job. For an end-user without much deeper knowledge, the biggest differences might be
XDG_PATHbased directory and
People often wonder why SQLite does not use the Git version control system like everybody else. This article attempts to answer that question. Also, in section 3, this article provides hints to Git users about how they can easily access the SQLite source code.
This article is not a comparison between Fossil and Git. See https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki for one comparison of the two systems. Other third-party comparisons are available as well - use a search engine to find them.
This article is not advocating that you switch your projects away from Git. You can use whatever version control system you want. If you are perfectly happy with Git, then by all means keep using Git. But, if Git is not working well for you or you are wondering if it can be improved or if there is something better, then maybe try to understand the perspectives presented below. Use the insights thus obtained to find or write a different and better version control system, or to just make improvements to Git itself.
The first stable release of Sublime Text 4 has finally arrived! We’ve worked hard on providing improvements without losing focus on what makes Sublime Text great. There are some new major features that we hope will significantly improve your workflow and a countless number of minor improvements across the board.
str(…)macro to handle them all.
int table = 13; int id = 37; str test1 = str(“SELECT * FROM “, table, ” where person_id “, id); str test2 = str(test1); //copies test1 to test2 str test3 = str(test2, test1); // returns concat of test2 and test1
test2 = test1; // acceptable, but wrong since test2 now points to test1 not copies it.
str(test1); // returns const char to use in printf like functions Ex: puts(str(*test1)); // prints test1;
Once, there was a civilization (the Lisp Machine world) a lot like ours, but more advanced, with greater powers (like symbolic computation, automated learning, and LISP).
Then, in one tragic moment (er, decade - the 1980’s), it was destroyed.
But because of the wisdom of Jor-El (Stall-Man), because he realized that the human race had the capacity for good, he sent us his only son (editor).
His name is Kal-El (elisp). He will call himself Clark Kent (Editor MACroS), but the world will know him as… Superman (Emacs).
I’ve had a good couple of years in terms of tool discovery. Rather than try to tweet about them in bits and bobs, I figured I would write up a few bits and pieces that I like.
In recent years many new build systems have emerged to replace traditional make. Although they all have different strengths and weaknesses, one common theme is improving execution performance of the build system.
Traditional multiprocessor make systems are generally efficient at scheduling tasks within a given Makefile. Given a dependency graph, child processes can be executed when their dependencies are satisfied and processor cores are available.
Unfortunately, this breaks down where multiple Makefiles are used across different directories or modules. The choice that a build system maintainer faces becomes:
Using per-directory Makefiles allows developers to compile individual directories in isolation, but doing so means a full build needs to drain out child processes at various points in the build, because the engine cannot recognize dependencies natively;
Using fewer Makefiles means more efficient full builds but more difficult isolated compilation, as the developer would need to change directories and specify the correct target to build.
However, there’s no reason that this choice is inevitable. If the full build can construct a single global dependency graph, but each directory still contains a partial dependency graph, a directory build can operate as well as traditional make and a full build can operate as efficiently as a newer build system. YMAKE attempted to build such a system, and do so without requiring any changes to per-directory Makefiles.
Specifying the global graph requires a new syntax to logically graft a child directory into the dependency graph. The remainder of Makefile syntax does not need to change, and conditionals can be used to fall back to recursive navigation if a global dependency graph is not supported. This means that the build system does not require developers to install new build tools to compile, so it still benefits from the ubiquity of make, but having YMAKE just makes the existing build system faster.
While Emacs proponents largely agree that it is the world’s greatest text editor, it is almost as much a Lisp machine disguised as an editor. Indeed, one of its chief appeals is that it is programmable via its own programming language. Emacs Lisp is a Lisp in the classic tradition. In this article, we present the history of this language over its more than 30 years of evolution. Its core has remained remarkably stable since its inception in 1985, in large part to preserve compatibility with the many third-party packages providing a multitude of extensions. Still, Emacs Lisp has evolved and continues to do so.
Important aspects of Emacs Lisp have been shaped by concrete requirements of the editor it supports as well as implementation constraints. These requirements led to the choice of a Lisp dialect as Emacs’s language in the first place, specifically its simplicity and dynamic nature: Loading additional Emacs packages or changing the ones in place occurs frequently, and having to restart the editor in order to re-compile or re-link the code would be unacceptable. Fulfilling this requirement in a more static language would have been difficult at best.
One of Lisp’s chief characteristics is its malleability through its uniform syntax and the use of macros. This has allowed the language to evolve much more rapidly and substantively than the evolution of its core would suggest, by letting Emacs packages provide new surface syntax alongside new functions. In particular, Emacs Lisp can be customized to look much like Common Lisp, and additional packages provide multiple-dispatch object systems, legible regular expressions, programmable pattern-matching constructs, generalized variables, and more. Still, the core has also evolved, albeit slowly. Most notably, it acquired support for lexical scoping.
The timeline of Emacs Lisp development is closely tied to the projects and people who have shaped it over the years: We document Emacs Lisp history through its predecessors, Mocklisp and MacLisp, its early development up to the “Emacs schism” and the fork of Lucid Emacs, the development of XEmacs, and the subsequent rennaissance of Emacs development.