Snapshots are the #1 feature of COW filesystems. I've been using them for a bit in btrfs and this feature is game-changing (and no, it hasn't eaten my data yet).
1,171 karma · joined February 20, 2007
Snapshots are the #1 feature of COW filesystems. I've been using them for a bit in btrfs and this feature is game-changing (and no, it hasn't eaten my data yet).
One thing I don't like about GCC's testing framework is the number of files. If you need to test 10 related things (say, diagnostics for a particular language construct), then you will have 10 different test files. I would much prefer for them to be in a single file. This is one of the goals of Testscript[2].
[1] https://blog.nelhage.com/2016/12/how-i-test/
[2] https://build2.org/build2/doc/build2-testscript-manual.xhtml
But there is something actively developed in that direction: https://build2.org and https://cppget.org
In fact, the package manager is pretty feature-complete, just the build system is still heavily developed.
Of course, don't expect either of them to be open source. Which means an open source ORM backend that depends on them can't be in an official Debian/Ubuntu/RH repository.
* GNU/Linux (.deb/.rpm), FreeBSD, Mac OS (virtually no Windows)
* KVM-based virtualization (virsh, libvirt, bridging)
* Network (ssh, rsync, OpenWRT, etc)
* Bash scripting ($* vs $@)
* Security (X509, letsencrypt, Yubikey, etc)
* ZFS/Btrfs/COW (one-shot VMs, etc)
At Code Synthesis we build development tools and you will help maintain the development/deployment infrastructure.
If you are interested, boris@codesynthesis.com.
The reason we don't use GitHub is because we like to be in control of things rather than relaying on someone else's whim. Maybe we could setup a mirror?
For C++ there is the CLI compiler that implements a similar idea (i.e., uses a DSL) but instead of using the usage itself as a specification, it is based on the class-with-members abstraction. While the result is not as terse, it is quite a bit more flexible. Plus it allows you to specify option type (i.e., int, double, string, etc).
From a single interface specification CLI will generate C++ parsers, usage printing code, man pages, and html pages. Here is an example of a real-world interface that is handled with CLI:
http://codesynthesis.com/products/odb/doc/odb.xhtml
The project page is here:
It seems to me that unless it is a complete one-to-one mapping, it is going to be a nightmare to explain what is supported and what is not.
Some people say that they use a 24" panel in the portrait mode for coding. I haven't tried it myself but one thing that I am curious about is whether their neck starts hurting. You see, if you have a text editor occupying all of the vertical space in such a setup, you cannot just move your eyes to be able to see the top and botton text. You actually have to move your head. I already feel this a bit on my 30" in the ladscape mode. That's why my emacs is not running at full-vertical-screen.
Or, to put it another way, you resort to uglyfying the lexer to overcome definiciencies in the parser.
It may look silly on the outset, but this is the book. Accounting is very idiomatic. If you are not "in", things just look backwards or outright idiotic, especially if you have math or similar background. This book bridges the gap between the common sense and accounting.
Sun to OS vendors: "Hey, we just promised developers they can run Java on your platforms. Now you go make it happen!"
Apple to Sun: "... you!"
http://www.codesynthesis.com/~boris/blog/2008/05/19/real-xml...
And you are right about the XML data binding tools. In most cases parsing XML itself is not what takes the bulk of the time. It is validation (against DTD, XML Schema, or ad-hoc), data conversion (e.g., from "123" string to 123 integer) and perhaps construction of some in-memory representation (with memory allocations that it involves) that take the bulk of the time. There are existing tools[2] that can performs the above tasks an order of magnitude faster than a general-purpose XML parsers by generating the tailor-made validation and data extraction code as well as data structures from XML Schema.
[1] http://www.codesynthesis.com/~boris/blog/2008/05/19/real-xml...
Good sense of design, Modern C++, compilers, source-to-source translation, object persistence, multi-threading, etc:
Travel hardware: ThinkPad T61
Software on both: 64-bit Debian unstable with xorg/sawfish wm (no Gnome or KDE), emacs, screen, g++, make, etc.
You are spot on. Here is an excerpt from a blog post on writing a GCC plugin:
The GCC AST itself is a curious data structure in that it is an implementation of the polymorphic data type idea in C (next time someone tells you that polymorphism works perfectly in C and they don’t need “bloated” C++ for that, show them the GCC AST). The base “handle” for all the AST nodes is the tree pointer type. Because the actual nodes can be of some “extended” types, access to the data stored in the AST nodes is done via macros. All such macros are spelled in capital letters and normally perform two operations: they check that the actual node type is compatible with the request and, if so, they return the data requested.
http://www.codesynthesis.com/~boris/blog/2010/05/10/parsing-...
Of course it is not called -- the object has failed to construct. There is no object. You cannot call a destructor on nothing. Now if some data member has been constructed but the call constructor failed, destructors for such members will be called.
If you want some more information on how this works, take a look at this intro to parsing C++ with a GCC plugin:
http://www.codesynthesis.com/~boris/blog/2010/05/03/parsing-...