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.
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.
It's worse than that. We don't actually know where it occurs. There are clearly some gems where it does, but it could also be occurring elsewhere in the VM.
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?
The problem is this[1]: strings are compound objects, which use 2 memory allocations. One for the object representation, the other for the memory holding the character array. The problem arises when you access the character array but technically no longer need the string object itself anymore. The C compiler notices that you don't use the pointer to the string object anymore, so it doesn't bother storing that on the stack. It is allowed to do this. The GC's mark phase now runs; it inspects all the stack frames and the global roots. It detects that no references to the string object exist and decides to collect it. There happens to be a destructor function associated with that memory object, which frees the character array, as the character array is manually memory managed. It blows up when you then try to access that character array directly.[2]
The correct way to handle this is to add the object reference to the GC's "root" set while you're using its guts, and removing it again when you're done.
Another possible solution is to allocate the string object and its character representation in one chunk of memory. This only works for immutable strings which never share substructure, though. The reason this works is that most conservative GCs will consider objects live as long as there is a pointer pointing to somewhere within a chunk of memory, not necessarily at the beginning.
[1] note: I'm not a Ruby coder but I fixed a very similar problem in a Lua implementation about 4 years ago. That one wasn't even conservative GC. EDIT: I told the story of that bug on HN 3 years (!) ago http://news.ycombinator.com/item?id=217189
[2] worse, it probably doesn't blow up immediately and instead causes memory corruption.
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.
