cracauer

Interesting stuff. Lisp or not. Lisp programmers often tackle interesting problems.

Excellent book to learn compile-time computing.

Too bad the jobs are all gone by now.

Tablets should have a HDMI/Displayport in so that you can directly use them as displays.

C++ finally catches up to Perl :-)

The FreeBSD experience with the upgrade also shows that this is not a smooth enforced upgrade.

This is bad in one aspect:

Google pays Mozilla a lot of money, mainly to keep Google search the default search engine in Firefox.

If that turns out to be illegal it could create a financial crisis for the Firefox browser and hence reduce diversity in web browsers.

Disappointing that this test doesn't report on how well suspend/resume works.

The OP could solve most of those problems by switching back to FreeBSD.

I would like to have a resource like this, but instead of the PoC I want to see the diff that fixed the flaw in the software.

Anything like that around? I know it isn't trivial.

You can have type checking in Common Lisp:

https://medium.com/@MartinCracauer/static-type-checking-in-t...

I have libraries of functions written in pure sh.

I use those functions in both scripts and my interactive shell (which is bash).

I cannot do the same with zsh as my interactive shell if scripting is supposed to stay POSIX/bourne shell. Which I want as I often do this in systemwide scripts or modify existing scripts (all plain sh). The incompatibilities do matter.

> It's also dynamically typed which disqualifies it for large collaborative projects.

You can add type declarations and a good compiler will check against them at compile time: https://medium.com/@MartinCracauer/static-type-checking-in-t...

Sadly format did not make it.

Surprising. You wouldn't normally think of Liberia and Myanmar having their shit together.

This is why my directories with shell scripts have a "make install" target. For execution they are copied to a place where they are unlinked before written new.

When using generational GCs it is of utmost importance to match the policies for moving things between GCs to the actual pointer interconnection pattern.

This can go really bad, for example in systems that keep caches/repositories of preallocated things for faster re-use. If they are anchored at global variables, or near global, then you need to treat those preallocated things special. You can't just go and move them every time even when knowing you will never collect them.

Generally, GC works better if you don't do tricks/optimizations with memory allocation and let just everything flow freely into the heap. If you do have to optimize allocation you generally have to teach your GC about your hack.

I am a friend of simple garbage collectors. Let initial placement be decided by running code.

Let later placement be decided by the order in which the heap is scavenged. That is what e.g. re-unifies array-of-pointer target instances. You scavenge the array of pointers and in the default case you line up the instances the pointers point to beautifully one after another. Even if the initial allocation had interleaving other memory. In that case your code gets faster after GC than before the data is first GCed.

Not wasted space. Unreleated space would do.

Keep in mind that you only have a tiny amount of L1 data cache lines. They are gone so quickly. If you can get a couple more struct instances in an array into those cache lines (without the cache lines holding unrelated nonsense as a byproduct of a memory fetch) that is a huge win.

The issue of L1 cache lines is more important than the size of the L1 cache. The granularity of the cache lines uses up the size of the cache very quickly if all cache lines are padded up with 3/4rd nonsense that you don't need right now.

I don't have anything new. I might have to re-write a GC for Clasp. Then I know :)

A better questions would be whether anybody has a moving, precise GC running on LLVM. Clasp with MPS runs, but that might be coincidence/luck.

Sure, you can change any of the individual properties.

But if you cannot move memory (adjust pointers like most GCs do) then you will have to deal with fragmentation, which slows down allocation (or causes other drawbacks).

Moving GC can also make the program faster due to memory compactation and hence being more efficient wrt CPU cache and TLB.

A GCed piece of nontrivial code can also be faster than a malloc/free solution.

The reason being that allocation can be much faster. The GCed code can allocate memory with as much as an increment of a pointer (and that is atomic, so no thread locking needed).

malloc/free always do full function calls, and they might/will descent into dealing with fragmentation (aka finding free space). Likewise, free() isn't free and cross-thread allocation/deallocation can further complicate things.

If you are interested in optimizing generational GC with operating system facilities:

https://medium.com/@MartinCracauer/generational-garbage-coll...

And a review of LLVM's GC facilities: https://medium.com/@MartinCracauer/llvms-garbage-collection-...

Overall message is that there are many different ways to get to the destination, and creative solutions are mixed in.

A quick look at what Quicklisp has to offer for libraries should quickly convince people that fooling around with anything but Common Lisp would be very energy-consuming.

http://blog.quicklisp.org/

No question about the headlines overstating.

But I don't think this is a rare situation. For example you can allow a bunch of users to restart and change a buildbot infrastructure (which runs as its own user, not root).

Those LEDs should be in-series with the camera's sensor power circuit. No software control at all.

ITA's customers before the Google acquisition were not interested in sharing large infrastructure that would make contiguous querying (as opposed to on demand when a consumer searches), presumably mostly for cost reasons.

The QPX search engine is actually the same behind Google flights and all the airlines and what Orbitz used to use. The limitation pre google/flights was the on-demand querying only.

Now the contiguous querying, obviously, gives you a load of useful historical data. After running it for a couple of years now they seem to feel confident that they can predict prices changes with enough accuracy that the payouts for misses will be an acceptable price for the publicity, or increased use of their other travel products.

(disclaimer: ex-ITA/Xoogler, opinions my own)

They write an article on polygraphs and do not mention Aldrich Ames?

WTF, NYT?

I still have this bug. https://github.com/zfsonlinux/zfs/issues/8396

Page faults from NFS client side aren't served by the server when they should (readonly map, reading a page). I could imagine this is related.

All that work, and still I had to use right-click "open image in new tab" to see the text of a meme?

Is anybody in there actually using that thing? (those in user-facing changes authority?)