Hello! Is there any chance that this would work with other language front-ends that generate LLVM IR?
3,597 karma · joined December 11, 2011
As a consumer, great!
http://webcache.googleusercontent.com/search?q=cache:wjD83Ex...
...
> There's still a JS/V8/Chrome for a dependency. On an application where we're rendering huge walls of text - we forgo native redraw. Crucial to response time. > What makes Atom a viable choice when there already is free, open source, native, cross-platform editors with great plugin ecosystems?
I guess maybe CoffeeScript isn't what turned you away?
It sounds like you might find https://www.google.com/webhp?q=suicidal%20exhaustion#q=suici... interesting.
Good luck! There are plenty of people out there who feel like you do. Just survive a day at a time at first.
crncosta indicated that there was an actual patent: "React is patented"
I'm curious to know what patents he is specifically referring to.
I've managed to fund some of the work by doing other contract work. It has also given me a lot of experience working with pretty much anything I want in the compiler, debugger, linker, run-time libraries, performance tools, C bindings generators, networking code, garbage collection, type systems and so much more. Some of this has resulted in further contract work, some has resulted in contributed fixes or improvements to other libraries.
(I'm now looking to potentially fund a student for some work this coming summer.)
Now, I'm taking a lot of what I've learned from that and starting up a small business (not looking for VC) to produce a new kind of developer tool. We plan to be open source and have some customizations and packaged products that businesses will be interested in and suspect we can fund ourselves that way. It'll be a long hard slog to get there, but we're pretty excited about what we're doing.
In general, I think there are a lot of things that could really use improvements. Our shells haven't changed much in the last 20 years. (I wrote a post about this last October: http://waywardmonkeys.org/2014/10/10/rich-command-shells/.) Almost everywhere you look, there are things that could be better. Most of them are a hard sell as a business. Some sort of increased infrastructure funding would be great.
Along those lines, there are programs that provide funding for some of those sorts of things. Stripe had an open source residency program for a short while. Mozilla funds some projects. The Knight Foundation funds a number of things a couple of times a year. Even Comcast has a funding program (http://techfund.comcast.com/). I'd love it if organizations over a certain size allocated some funding for some work that might benefit them, but would also have a wider benefit. If someone has 50 or 100 programmers on staff, they can probably afford to sponsor someone for 3 months or a year at a time. And who knows what might come of some of it...
Easy: get up early and practice. You don't have to wait until after work to practice.
I spent some time in the mid-1990s building a product from 5-7am, and then going and doing an office job to pay bills for the day. It works.
They also produce actually good quality news from solid reporters.
I've occasionally wondered if we should take the old emulator sources and re-package them as a separate repository. It isn't clear that anyone knows how to make them run any longer or whether or not they'd run on anything other than LispWorks or if this would be of anything other than a historical curiosity.
Oryol is a great new take on some of the core concepts of Nebula 3, but in a C++11 environment and being able to rely upon more modern compilers, libraries, etc.
They are willing to talk to people about the licensing. They're nice folks, although often pretty busy. CLASP supports using both MPS and Boehm as well.
As for the Open Dylan exception ... yes. But the other thing to understand there is that both MPS and what is now Open Dylan were developed at Harlequin in the 1990s and MPS's original "client" was Open Dylan.
There are a few things that are worth taking note of though ...
One is that things that use addresses in memory need to be able to deal with those addresses changing. An example of this are common implementations of hash tables (due to hashing using the address). MPS provides location dependencies (http://www.ravenbrook.com/project/mps/master/manual/html/top...) to deal with this.
Another is that when you call into C / foreign code, you want to be able to pin your object down so that it won't move. This is commonly an issue with byte vectors / strings. For that, the language / libraries / compiler should support pinning and unpinning objects. The way that Dylan does this in the native code generator is that it makes sure there's a stack reference to the object which is enough for the GC to not move it. This is only good for short-lived things though as you don't want to disrupt GC for too long.
Another thing to take note of is that you sometimes want to store an object reference in native code and out of reach of the GC. A common situation where this happens is storing user data or callbacks. In this situation, we can register a Dylan object to have a handle which we can pass to native code. With this, we register the object, then export it to get a handle, we pass the handle to native code. When we get a handle from native code, we import it to get back to the original Dylan object (which may have moved). We can unregister it when we're all done.
register-c-dylan-object(handle);
%uv-handle-data(handle.raw-handle) := export-c-dylan-object(handle);
...
let handle = import-c-dylan-object(%uv-handle-data(raw-handle));
apply(handle.callback, args)
As for Dylan, Dylan can use Boehm (and does for now in the C and LLVM backends), which is conservative.
However, Dylan can also use MPS (http://ravenbrook.com/project/mps) which is a much more advanced GC that does copying/compacting and all that. Dylan uses MPS with the compiler backend that generates native code.
The plan is that once the LLVM backend is up and running using Boehm, efforts will be made to get it working with MPS.
Julia uses a home-grown GC, but I'm not familiar with it or its characteristics at all.
LDC (D with LLVM) is written in C++, so they invoke LLVM APIs, but I don't know what they generate (bitcode or machine code).
Julia is written in C++, they invoke LLVM APIs, they call the JIT.
CLASP is written in C++ and Common Lisp, they invoke LLVM APIs, but I'm not sure if they only JIT or if he stores anything to disk yet.
And so on ...
Did KHTML exist back then and was it good enough that it deterred more KDE / Qt folks from working on Mozilla? I don't recall as it has been ages. Of course, KHTML went on to become the foundation of WebKit ... so much history!