jjore

See also http://www.wsj.com/articles/new-clues-why-women-get-broken-h... for occasionally fatal and measurable symptoms of psychogenic (or vagus mediated?) heart attack.

Here, our ground-rules were recently posted. https://www.facebook.com/notes/seattle-clown-jam/clown-jam-g.... This is one potential model where performers can do challenging things in an environment that allows mistakes.

Similarly, we have a Circus Open Mic in Seattle (https://www.facebook.com/events/533760116677373/) where ground rules are that admission is free and open to the public but it's generally a supportive and in-community audience. We've had comedians, magicians, aerialists, acrobats, jugglers, extremely weird people, clowns, and strip history lessons.

I present both of these as ideas for ways to develop and grow without being subject to eternal Google search indexing and YouTubing by random civilians. I think both of these seem to come down to controlling the venue and rules. If you experiment in a bar or club, you're in the wild.

We do these in theatres, black boxes, and dance/performance spaces. This allows us to control the door.

We solve this problem in Clown Jam by essentially just being audience for each other. It's open to anyone who wants to come practice but no one is a "civilian" and there are reasonable person ground rules about posting pictures and video.

The Seattle transit system has been running out of money. They cut free rides to get a bit of change back. We're just not taxing enough to support it.

If it's not upgradeable then it's disposable. Get the new one next time.

I can't read APL but perhaps that is readable. I'm unsure that other common dynamic languages like Ruby or Python are readable purely in comparison purely for using http://en.wikipedia.org/wiki/COBOL#Verbose_syntax.

Well, the problem here is that C using gems are going to often be memory corruptingly buggy until and unless either the gem source is updated to declare the proper parts volatile or Ruby's own C API is reworked to evolve this bug out of existence and then gems would have to be updated to use the API anyway.

Both problems are hard and the current state of affairs is apparently some random amount of the time we'll get memory corruption bugs.

Right now, doesn't the GC traverse the entire heap and keep all objects where the memory's value looks like it might possibly be a pointer to some other object in memory?

This certainly isn't an awesome solution but couldn't the GC backtrace(3) the current process and look at %eax at all C stack frames to additionally include that value in the "pointers currently plausibly in flight" list?

A fairly commonsensical approach is to just require all extension authors to annotate their code properly. At some basic level, this happens with Perl with its oft-maligned DSL for generating C code that happens to do all the right declarations. You might then end up writing your code using more macros. It's certainly not pretty but it is sound.

A plausible rewrite of that function in an XS for ruby would leave the function declaration and wrapper code up to your equivalent of xsubpp to execute your DSL and transform the wrapped code to fully functional C. If you build a C using extension from Perl, you'll find an XS file like http://cpansearch.perl.org/src/SIMON/Devel-Pointer-1.00/Poin... which during the `perl Makefile.PL && make` step is transformed via `xsubpp Pointer.xs > Pointer.c` and then compiled as normal C.