WanaDecrypt0r

Reading up on how WanaDecrypt0r works but details are scarce. It looks like a heap spray^1 with an unlink exploit but no confirmation of that anywhere.

No wonder Google is investing in Fuchsia?

^1: Actually, that came from some remark I read but I disagree. It might be as trivial as unlink. That is, set up non-paged memory in a deterministic manner, exploit a buffer overrun in SMB to corrupt a part of the kernel heap, unlink into the payload. I don't see why it would need a heap spray.

EDIT: Explanation here.

Log 051117

I am trying to figure out why the constructor of a combinator is passed a pointer to the VM. It's not a bad design decision, any combinator might want to poll the VM for information for various reasons. Might have been operator overloading where you needed to inspect a global table? But, of course, combinators which reference the current runtime are hard to ship. I might want to cut that but at the risk that I would need to introduce it again at some stage later.

Stuff you know you don't know, stuff you don't know you don't know. And all that.

Log 051017

Well. Apart from dreaming, mobile code is pushed into the far future because there are still too many mundane tasks to do. I didn't even implement string unescaping yet, so that's why Hello World doesn't work right. And the more pressing matter after that is implementing a sane manner of being able to link in C++ defined combinators and some kind of sane library for primitive IO and standard operators. That's at least about half a year's of work before I even get to the point I can start thinking about linking in matrix operations.

So, I better get coding.

Not so bad

It dawned on me that a lot can be solved by extracting portable combinators from the runtime instead of making all combinators portable. That would solve the problem that I could 'mess' up a perfectly fine small language.

So for future's sake

Well great. So, what to do? I have an eager combinator evaluation system. What do you naively need to make it mobile:

1. The term being reduced (elsewhere) must be transportable, and
2. the combinators it invokes must be transportable. Moreover, 
3. the end-result is a term which must be transported back.

The term is a tree of combinators not referencing anything else (if I got the invariants right), so that just needs a means of serialization.

A combinator naively is just a piece of code, so when you're able to serialize that you're halfway there. The other half is that combinators might reference other combinators but that's easy to solve with standard compiler technology. A combinator can be described as a self-contained piece of code referencing external symbols and all you need to do is sweep, ship, and link.

Problem solved, right? However: Verbose, computationally intense, might end up sweeping the entire program, possibly too fine-grained in that you need to gather and link myriads of combinators, doesn't solve distributed scheduling and coordination let alone local exceptions..

And then there's the stuff I didn't think of yet.

Worst case: I manage to corrupt a perfectly fine small language in such a way that it becomes unusable both for stand-alone or distributed computing.

So. Cheers.

Scrap mobile code? For now? For ever?

Right. So the master plan is to develop a language which combines ideas of statistical computing and mobile code. Mobile R, in short.

Great ideas!

But I've been reading up on mobile code and there's a) either no market for that or b) it falls squarely into the category of academically uninteresting things to do but technologically one of the hardest stunts to pull off.

That is, if you walk into a university these days the response will likely be "So you can migrate combinators, huh? Neat. My paragliding functor does the same and I've published tons of papers about that."

But it's ridiculously hard to implement the functionality in such a way that you actually get to the point you have a tool people will be willing to use.

Even after trivializing the heck out of it, I am looking at, what, three years of development?

Log 050217

I committed the changes which cut operator overloading. I wasn't very sure about it because I saw it as a means of solving the expression problem for this language. However, the expression problem occurs in larger languages where you don't have all sources under your control because some code, modules, are maintained by others.

This language doesn't have users, I want to grow it into something domain specific, all source code is fully under control by the one user which is me. And the expression problem shouldn't occur to me or my users since I don't intend it to be used for general software engineering purposes.

As such, it was a solution to an entirely academic problem which only cost a steep amount of CPU cycles per lookup. And, in the unforeseen event I actually grow Egel into a language which attracts end-users, I imagine they care more about performance than about solutions to problems which don't exist.