cracauer's comments

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.