jharsman

Emacs solo actually contains functionality for just that, the below snippet which allows exporting xref buffers to grep format by pressing 'E'. You can then use wgrep etc.

  ;; Makes any xref buffer "exportable" to a grep buffer with "E" so you can edit it with "e".
    (defun emacs-solo/xref-to-grep-compilation ()
      "Export the current Xref results to a grep-like buffer (Emacs 30+)."
      (interactive)
      (unless (derived-mode-p 'xref--xref-buffer-mode)
        (user-error "Not in an Xref buffer"))

      (let* ((items (and (boundp 'xref--fetcher)
                         (funcall xref--fetcher)))
             (buf-name "*xref→grep*")
             (grep-buf (get-buffer-create buf-name)))
        (unless items
          (user-error "No xref items found"))

        (with-current-buffer grep-buf
          (let ((inhibit-read-only t))
            (erase-buffer)
            (insert (format "-*- mode: grep; default-directory: %S -*-\n\n"
                            default-directory))
            (dolist (item items)
              (let* ((loc (xref-item-location item))
                     (file (xref-file-location-file loc))
                     (line (xref-file-location-line loc))
                     (summary (xref-item-summary item)))
                (insert (format "%s:%d:%s\n" file line summary)))))
          (grep-mode))
        (pop-to-buffer grep-buf)))
    (with-eval-after-load 'xref
      (define-key xref--xref-buffer-mode-map (kbd "E")
                  #'emacs-solo/xref-to-grep-compilation))

This is very true. There several reasons why most EHRs are so bad:

1) The people who pay generally do not use the system. This is true for enterprise software in general and leads to vendors prioritizing having all features organizations ask for (regardless if they are a good idea or not) and also prioritizing features management deems important over fundamental workflow, UX and polish in general.

2) EHRs are very large and complex and can almost always gain more customers by gaining even more features and replacing smaller more specialized systems. A typical EHR will have features for ordering tests and viewing results (for clinical chmistry, microbiology, radiology and more special stuff like physiology etc), appointments and resource planning (rooms, equipment, personnel, staffing), clinical notes including computing scores and values based on other values, medication (ordering, administering, sending prescriptions electronically) and administration (admissions, discharge, payment, waiting lists). That is a lot of different stuff!

3) Once a vendor wins a contract and installs their EHR, very little can be gained by improving the lives of users. Contracts and sales cycles are very long, and the vendor gains very little financially by improving the system. So many vendors are focused on charging money for customer specific features or adding new features to win new tenders.

I'm not sure what the solution is, public alternatives have failed spectacularly since they are typically run by public administrators who have even less of a clue how to develop software and what users want than the vendors.

Yes, the standard solution to this is to use the curl if the scalar valued noise field. This gives you a vector field which is perpendicular to the gradient and i divergence free.

Demo is called Blunderbuss, by Fairlight: http://www.pouet.net/prod.php?which=53950

Youtube: https://www.youtube.com/watch?v=VCpYH8yDK8g

I was an early adopter of Mercurial and the teams insistence that file names were byte strings was the cause of lots of bugs when it came to Unicode support.

For example, when I converted our existing Subversion repository to Mercurial I had to rename a couple of files that had non ASCII characters in their names because Mercurial couldn't handle it. At least on Windows file names would either be broken in Explorer or in the command line.

In fact I just checked and it is STILL broken in Mercurial 4.8.2 which I happened to have installed on my work laptop with Windows. Any file with non ASCII characters in the name is shown as garbled in the command line interface on Windows.

I remember some mailing list post way back when where mpm said that it was very important that hg was 8-bit clean since a Makefile might contain some random string of bytes that indicated a file and for that Makefile to work the file in question had to have the exact same string of bytes for a name. Of course, if file names are just strings of bytes instead of text, you can't display them, or send them over the internet to a machine with another file name encoding or do hardly anything useful with them. So basic functionality still seems to be broken to support unix systems with non-ascii filenames that aren't in UTF-8.

Dyalog launches multiple threads for certain operations if the arrays are large enough to justify the overhead.

That's not how lossless compression of JPEGs work.

Besides removing information from the file that doesn't affect the rendered image (like EXIF data), lossless recompressors typically replace the huffman coding of DCT coefficients with a more efficient arithmetic coder. So you don't start over from raw pixels, but you replace the type of compression used with a more modern and efficient algorithm. That means ordinary software can't read the JPEG (since you've essentially created a new format) but you can just decompress into standard JPEG whenever someone wants to look at the image.

Yes, the actual burning fuel part is just random noise, which doesn't look very very good. I mention it as a possible imrpovement under "Better looking fuel".

I can't get your example code to work, but that is a completely different technique, ray marching a volume displaced by a noise function. This gives nice 3D-looking flames, but the movement tends to look like a scrolling noise function. And it's harder to use arbitrary burning shapes, my simulation supports drawing anything and it will burn.

Traditionally TVs only support 60 Hz refresh rates (or 50 Hz for older PAL sets), so you either render a new frame for each frame the TV can refresh, or you display a frame for two TV refreshes.

Thi sisn't strictly true any more, since many TVs now support 72 Hz (to be able to display 24 fps content like film), but my guess is that doesn't have wide enough support to rely on.

You don't get high bandwidth utilization by pointer chasing unless you have many threads doing it and you switch threads while waiting on memory. That's true for GPUs, not for typical server workloads running on CPUs.

I find it really weird that the article says:

It’s curious that we have low cache hit rates, a lot of time stalled on cache/memory, and low bandwidth utilization.

That's typical for most workloads! Software is almost never compute or bandwidth bound in my experience, but instead spends most of its time waiting on memory in pointer chasing code. This is especially true for code written in managed languages like Java (since everything typically is boxed and allocated all over the heap).

Having static preferences that never change does indicate stagnation.

But the proverb in the form given is dumb.

Sweden does have very high taxes, but they are not the highest in the world. Belgium and Denmark have higher rates (measured as percentage of GDP).

See http://en.wikipedia.org/wiki/List_of_countries_by_tax_revenu...

If your requests are CPU intensive, Node.js won't help since it doesn't support preemption.

And even if you're primarily IO-limited, a single request that consumes too much CPU will cause queuing.

Garbage collected systems typically implement allocation with a simple pointer bump. This is possible because values are moved in memory by the garbage collector, updating references automatically. You can then compact all the empty space when collecting garbage, making allocation easy.

This is obviously faster than malloc which is what people compare with when they say allocation is faster with a garbage collector. Collecting the garbage, i.e. de-allocation, can be more expensive though, since it might require scanning large parts of the heap.

Since games generally use region based allocators , the performance gain is probably very small there. If you make lots of calls to malloc, then the gain would be larger.

Note that writing data to a single disk (or SAN array, or RAID controller) really isn't durable either, even if the the data does actually get to the disk and isn't in a write cache somewhere.

What if that disk crashes, or the SAN array brakes and kills all the data, or the data center burns down?

The PS3 has 256 MB system RAM and 256 MB dedicated video RAM. So it has twice as much RAM as the Raspberry Pi.

Presumably to find out whether the difference lies with the filesystem or somewhere else?

If Linux is still much faster, even with the same filesystem, you have eliminated one variable.

You can't have files named like the old DOS devices: CON, LPT, AUX, PRN etc. This is originaly due to CP/M backwards compatibility, it didn't have directories so magic files were udde to pipe stuff to printers and other devices.

Sounds like you want XKeymacs it gives Emacs keyboard commands to all Windows applications, including a kill ring.

http://www.cam.hi-ho.ne.jp/oishi/indexen.html

The 5D uses a very large aperture f 2.8 which you'd normally never use for a landscape shot in daylight. This leads to a very shallow depth of field and much less detail.

Provided you still have source code and development tools available, the problem in cases like this usually isn't the language. Even APL is pretty easy to pick up if you have a book or someone to teach you.

The bigger issue is that the application you need to fix is mission critical, undocumented and contains massive amounts of spaghetti code. There usually aren't any tests, source control might not be used and it's far from certain there are automated builds or deploy scripts.

In some cases you might not even have source or the tools to use it, and then you have much bigger problems. But the language usually isn't the main problem.

readdir() is implemented in libc, not the kernel. The kernel interface is getdents() and that has a configurable buffer size.

A better interpretation might be "probability this would happen if results were governed purely by chance". Note that the distinction is important if the process is in fact governed by chance!

Lets say I roll a dice two times and get a six both times. The probability of this happening is 1/36 or about 3%.

Would you say I have established with a 95% confidence interval that the particular die I'm using always rolls six? No, because you have good reason to believe that the the results are in fact random. Or in other words, you have a strong prior belief that the hypothesis you're testing is false.

You only get hit in the head at matches, and only if you choose something where striking at the head is allowed. And even if you commit completely to your training, matches will be months apart.

Or just try starting with Bjj or something where there's no strikes to the head if you're worried.

When I read really great code, I often think "This is all there is?". It seems like there is too little code to do all the things that it does. Or what is there seems trivial, so simple that it couldn't have required any thought or effort to produce.

Bad code is full of stuff, it twiddles bits here and there, does complicated things in nested loops and works very hard to accomplish very little.

This might make bad code seem more interesting, at first glance it seems like it does more, when in fact it generally does less, just with much more complexity.

You might want to google for "separating axis test", it is a very simple technique that allows you to detect collisions between any two convex polygons. It can also handle continous collisions detection for translation (your moving grenades) very easily.

In your axis-aligned case, you would project the objects you test on both axes (x and y). If the do not overlap on any one of the axes, they do not collide, otherwise they do. To handle movement you project each objects movement vector on the axes as well and add that to the objects projected interval.

To find out which grid squares that are covered by a polygon amounts to resterization, which you can find many tutorials for with google.

Axis aligned boxes are trivial to rasterize. For more complex shapes you write a rasterizer for triangles and handle arbitrary polygons by breaking them up into triangles (google "ear clipping").

I'm not surprised it doesn't make much of a difference with HTML since the markup contains so much ASCII. But 25 vs 18 kB is almost 40%. That might not be insignificant depending on how much text you're storing.

But it's a nitpick really, I just thought it he should have noted some of the disadvantages to UTF-8 as well.

If you're representing text which contains lots of characters that aren't in ASCII, like say Chinese, UTF-8 will consume much more storage than necessary. There are many languages where non-ASCII characters are extremely common.

He misses a very useful property of UTF-8 as well, it never contains null bytes. This trips up all sorts of heuristics for detecting binary files in various programs if you use e.g. UTF-16 for mostly ASCII text, since it then will contain lots of nulls.

UTF-8 is a very clever way to avoid problems on systems suffering under the mistaken assumption that text is 8-bit byte strings (cough UNIX cough), but that doesn't make it the ideal choice every time.

It is still very common for cross platform tools to not handle file names with non-ASCII characters for example. Both Mercurial and Git suffered from this last I looked.

The reason is that they treat file names as byte strings instead of text in some encoding, and therefore cannot translate to the proper encoding on platforms which treat file names as Unicode text, like Windows and OS X. OS X also uses a somewhat unconventional normalization form, which means you need to handle normalization as well.