161–170 of 324 posts
> Finally, you can also use ChakraCore as the JavaScript engine in Node. This is interesting. You can use it as an alternative to v8 for node.js
Oracle was working on getting node to run on the JVM, but it wasn't really open and it looks like it was abandoned: https://avatar-js.java.net/
Here's hoping EdgeHTML will also get open sourced. I know they've talked about it internally.
A few years ago, the trendy naming convention was Kit. Now it's Core, I guess. Will we stop wishing we were Apple one day?
> ChakraCore is a fully capable JavaScript virtual machine that has the exact same set of capabilities and characteristics that are supported by Chakra, with two key differences. First, it does not expose Chakra’s private bindings to the browser or the Universal Windows Platform, both of which constrain it to a very specific use case scenario. Second, instead of exposing the COM based diagnostic APIs that are currently available in Chakra, ChakraCore will support a new set of JSON based diagnostic APIs, which are platform agnostic and could be standardized or made interoperable across different implementations in the long run. As we make progress on these new diagnostics APIs, we plan to make them available in Chakra as well.
From: https://github.com/Microsoft/ChakraCore/wiki/Architecture-Ov...
Earlier quoted context omitted.
Even at the MOST EVIL Time of Microsoft some parts of Microsoft were very PRO Open Source even while they said "Linux is Cancer." Big Corporations can have mixed messages. Apple (My most hated company in Tech has also been very good to Open Source with some projects)
I'm genuinely curious which projects you are thinking of when you mention Apple. Shedding GPLv3 and refusing to (for example) update Bash because they do not want to use anything licensed under GPLv3 is pretty.... I dunno, I'm just curious what projects you're thinking of when you say that. The walls of that garden are pretty high.
Earlier quoted context omitted.
Even at the MOST EVIL Time of Microsoft some parts of Microsoft were very PRO Open Source even while they said "Linux is Cancer." Big Corporations can have mixed messages. Apple (My most hated company in Tech has also been very good to Open Source with some projects)
I'm genuinely curious which projects you are thinking of when you mention Apple. Shedding GPLv3 and refusing to (for example) update Bash because they do not want to use anything licensed under GPLv3 is pretty.... I dunno, I'm just curious what projects you're thinking of when you say that. The walls of that garden are pretty high.
GPL isn't the only license in town, and clearly there are disadvantages to it.
I've seen that a partial Linux support is on the roadmap, but does anyone know if there is a way to compile it with gcc or clang, or if it's on the roadmap ?
It doesn't look like it builds yet. See https://github.com/Microsoft/ChakraCore/wiki/Roadmap .
Earlier quoted context omitted.
Slight derail but I find it interesting that the Swift team is tackling the fragile ABI problem with v3... Something C++ could have done at any time, enabling portable and interoperable C++ interfaces. (There's no reason clang importer couldn't surface C++ or any other language to Swift for that matter)
Even if you can easily parse C++,[1] there are a lot of practical impediments to binding to C++ libraries. If an API exposes templates, or relies on constructors/destructors, it's very hard to call that from non-C++ code. For example, SpiderMonkey wraps JS pointers in C++ objects and uses RAII to register roots being held by C++ code with the JS garbage collector. Handy, but more or less impossible to call from non-C…
Also, the reason you could only get the AST as a XML dump was because of the same shortsighted mindset.
Small thing, but nice to see that the API is exposed as C (easy to write bindings for) instead of C++ (near-impossible to write bindings for).
Slight derail but I find it interesting that the Swift team is tackling the fragile ABI problem with v3... Something C++ could have done at any time, enabling portable and interoperable C++ interfaces. (There's no reason clang importer couldn't surface C++ or any other language to Swift for that matter)
It could have, but a standardised ABI is a terrible idea. Once you commit to an ABI you're stuck with the tradeoffs you make. If C++ had specified a stable ABI 20 years ago, we'd all be using setjmp and longjmp for exceptions, and small string optimisations and such would be impossible.
I don't really see the big deal tbh. C++ code compiled with GCC was ABI stable between GCC 3.4 (Apr 2004) and GCC 4.9 (Apr 2014), and you can still use use the -fabi-version switch today to generate code against older ABIs. Hell, libstdc++v5 (shipped with GCC 3.3) is still packaged for most distributions.
Earlier quoted context omitted.
A lot of small medical and dental practices operate on one or two PCs. Windows doing things like uploading your calendar and address books could end up being a HIPAA violation. Enterprise customers are fine because they have controls for everything, but small offices running Windows 10 Pro aren't so lucky.
On all versions of Windows 10 you can disable OneDrive, and thus it will not upload locally stored calendars or address books.
Earlier quoted context omitted.
Slight derail but I find it interesting that the Swift team is tackling the fragile ABI problem with v3... Something C++ could have done at any time, enabling portable and interoperable C++ interfaces. (There's no reason clang importer couldn't surface C++ or any other language to Swift for that matter)
Yeah. As much as I absolutely love C++11, and use its features constantly, if I had to make the hard call: "do I get lambdas, or do I get some extern ABI marker I can use to opt-in to a non-fragile ABI, with field and vtable offsets linked as symbols and return types mangled into function names", I would have made the (incredibly depressing) choice for the latter, as it makes C++ suddenly able to be used in ways that…