I'm trying to understand if there is any other way to access the WebKit API directly from from a Haskell (ghc-7.10.2 currently) program without having to go through something like webkitgtk3, which is a Haskell wrapper around WebKitGTK.
It appears WebKitGTK does not expose the full WebKit API, for example these are offered by WebKit:
HTMLCanvasElement # developer.apple.com
CanvasRenderingContext2DClass # developer.apple.com
but not by WebKitGTK:
WebKitDOMHTMLCanvasElement # webkitgtk.org
Is there any way to access the WebKit API of a running WebKit.app or Safari.app especially on OS X but also Linux and Windows?
P.S. Some background to this: I'm developing an application using GHCJS, but since GHCJS is so much slower (and doesn't integrate with all Emacs IDE features, I think), I also want to be able to compile the same (or almost the same) code base using GHC. So I got familiar with webkitgtk and even spent several days trying to get webkitgtk-2.4.9 to build on OS X via Homebrew, because webkitgtk3 only currently builds against 2.4.9, only to find out that the nice and fully featured Canvas API which WebKit exposes is not at all available through WebKitGTK. Hence the search for alternatives. And it is also for this reason I'm adding ghcjs — it is very likely that other users of GHCJS will find this post interesting.
Related
GraalVM has so many surprising capabilities. But one thing I haven't seen, but would like to, is to be able to run a GraalVM application in a browser. Sources like this (Top 10 Things To Do With GraalVM) shows interop with Node.js, but not running a compiled application in the browser.
Is this possible? If so, is there documentation on this? Thanks!
Well, it looks like this may be possible using Webassembly. From the Graal VM lead Thomas Wuerthinger: https://twitter.com/thomaswue/status/943592646915878912?lang=en
Webassembly is useful for statically typed languages (as LLVM
backend). I am not aware of any Ruby, R, or Python implementation
successfully targeting Webassembly. Graal VM will be able to run via
Webassembly in the browser. It also has a "native" mode with
standalone binaries.
So if you're coding in something like Clojure or Python and planning on compiling to Webassembly via Graal VM, you would likely run up against the same restrictions that Webassembly has, such as the browser sandbox and only being able to access web APIs. It will be interesting to see if those boundaries can be communicated through error messages or other compile-time checks.
It would be very interesting to see a browser that embeds GraalVM and can run its engine for languages, even if only for JavaScript initially.
Currently, there's no such browsers, as far as I know. Maybe an interesting first step would be to take Electronjs, and try replacing the version of node they use with the version of node.js from GraalVM. It's not trivial, since they introduce some changes to the stock node.js and GraalVM introduces some changes when replaces the JavaScript engine with its own implementation.
However, it definitely should be possible to achieve.
I'd like to generate a flame graph for my node.js app. Unfortunately, my dev box is OSX (doesn't support utrace helpers, per the linked article) and my production box is CentOS (doesn't even have dtrace).
I've found some indication that something like SystemTap might be a dtrace alternative, but I've been unable to cobble together an effective working way to generate the appropriate stacks.out file to feed into stackvis.
Does anybody know of a decent tutorial on how to get this up and running? I'd prefer it on CentOS (so I can examine my production app) but OSX would also be sufficient.
From the latest google searches, people are unhappy with SystemTap on Centos, but here is an article http://dtrace.org/blogs/brendan/2012/03/17/linux-kernel-performance-flame-graphs/ that was referenced by someone's FlameGraph github project https://github.com/brendangregg/FlameGraph
I would say move towards the real solution, of getting dtrace installed rather than relying on the work around.
On Linux, the perf_events profiler can be used to sample stack traces, and has JIT symbol support. For node.js, you need to be running version 0.11.13 or higher, with the v8 option --perf-basic-prof. That option creates a /tmp/perf-PID.map file for symbol translation, which perf uses. Once you have perf profiling stack traces with JavaScript symbols, you can then create flame graphs using stackcollapse-perf.pl (from the FlameGraph repo) on the output of "perf script".
I wrote up the full instructions here: http://www.brendangregg.com/blog/2014-09-17/node-flame-graphs-on-linux.html
This question already has answers here:
Is it possible to create desktop applications with node.js? [duplicate]
(5 answers)
Closed 7 years ago.
Is there a way to compile a node.js application?
I maybe very late but you can use "nexe" module that compile nodejs + your script in one executable: https://github.com/crcn/nexe
EDIT 2021: Nexe's latest release is from 2017 and it appears that development has otherwise slowed, so the more-widely-used alternative from Vercel should also be considered these days: pkg
Node.js runs on top of the V8 Javascript engine, which itself optimizes performance by compiling javascript code into native code... so no reason really for compiling then, is there?
https://developers.google.com/v8/design#mach_code
EncloseJS.
You get a fully functional binary without sources.
Native modules also supported. (must be placed in the same folder)
JavaScript code is transformed into native code at compile-time using V8 internal compiler. Hence, your sources are not required to execute the binary, and they are not packaged.
Perfectly optimized native code can be generated only at run-time based on the client's machine. Without that info EncloseJS can generate only "unoptimized" code. It runs about 2x slower than NodeJS.
Also, node.js runtime code is put inside the executable (along with your code) to support node API for your application at run-time.
Use cases:
Make a commercial version of your application without sources.
Make a demo/evaluation/trial version of your app without sources.
Make some kind of self-extracting archive or installer.
Make a closed source GUI application using node-thrust.
No need to install node and npm to deploy the compiled application.
No need to download hundreds of files via npm install to deploy your application. Deploy it as a single independent file.
Put your assets inside the executable to make it even more portable.
Test your app against new node version without installing it.
There was an answer here: Secure distribution of NodeJS applications. Raynos said: V8 allows you to pre-compile JavaScript.
You can use the Closure compiler to compile your javascript.
You can also use CoffeeScript to compile your coffeescript to javascript.
What do you want to achieve with compiling?
The task of compiling arbitrary non-blocking JavaScript down to say, C sounds very daunting.
There really isn't that much speed to be gained by compiling to C or ASM. If you want speed gain offload computation to a C program through a sub process.
Now this may include more than you need (and may not even work for command line applications in a non-graphical environment, I don't know), but there is nw.js.
It's Blink (i.e. Chromium/Webkit) + io.js (i.e. Node.js).
You can use node-webkit-builder to build native executable binaries for Linux, OS X and Windows.
If you want a GUI, that's a huge plus. You can build one with web technologies.
If you don't, specify "node-main" in the package.json (and probably "window": {"show": false} although maybe it works to just have a node-main and not a main)
I haven't tried to use it in exactly this way, just throwing it out there as a possibility. I can say it's certainly not an ideal solution for non-graphical Node.js applications.
javascript does not not have a compiler like for example Java/C(You can compare it more to languages like PHP for example). If you want to write compiled code you should read the section about addons and learn C. Although this is rather complex and I don't think you need to do this but instead just write javascript.
I had a fresh look at Haxe again recently and realized that I had overlooked some of its elegance before. But I guess it lacks some visibility among the developers still.
So my question is, does anybody here use it for production? If so, how do you use it? What are the gotchas or difficulties you encounter? Do you recommend it for future projects?
I use Haxe to develop all my Flash applications, and I love it. I develop on Linux and with Emacs,
and I really like how I can make Haxe fit within my preferred development environment. I just use
simple Makefiles that look something like:
project.swf: Project.hx
haxe project.hxml
It's really easy to get started in Haxe, and it's very elegant. I've
had no problems at all using Haxe as compared to using the Adobe Flash
builders, and have developed a bunch of big projects including PanningPedagogy, The Orchive,Cantillion and Audioscapes.
I've released the source code to all of these as GPL on SourceForge, check them out at:
https://sourceforge.net/projects/panning/
https://sourceforge.net/projects/orcaannotator/
https://sourceforge.net/projects/cantillion/
https://sourceforge.net/projects/margridflash/
You might find some useful information in the lists of Projects Using Haxe and People Using Haxe.
My company uses Haxe for production use. For programming swf content is absolutly no problem on the technical side. Using it on the server side is a little bit harder. If you Haxe for PHP you sometimes have some problems with typing (this is more or less a PHP problem). The neko vm is very stable and very very fast but it takes some time to get it running with all you other server software (mysql, apache - mod_rewrite), but once you got it you it is very stable.
We used it for generation swf applications, tried the possibilies of Haxe JS. Also we created socket server for a multiplayer game and start to generate all our webpages with Haxe PHP or neko.
The community is very helpful, the documentation is sometimes a little bit to short.
This is only my opinion and the experiences I made.
For those of us who don't know what Haxe is, it's a programming language for developing web apps. It has multiple compiler targets (Flash, php, JavaScript, and the Neko language's VM)
Welcome to haxe [haxe.org]
Haxe entry on Wikipedia
Haxe are currently gaining more popularity as a cross-platform development (mainly for game development) tools thanks to NME/OpenFL: http://www.openfl.org/
Write once in Haxe and deploy it to Flash, Android, iOS, and more..
HaxeJS is very good for web production, it allows to use all the underlying js modules while giving extra abilities like pre-processor, typed fields, conditional-compilation, classes, haxe libraries, refactoring and auto-completion from IDE etc.. plus its very quick to compile and output ready-to-use js files.
I haven't tried microsoft typescript, but so far I've been using HaxeJS for both client and server (nodejs) on a few production projects and it feels a great choice. The only issue is if i want to share js libraries or npm modules with others, I'll probably need to rewrite the js by hand then.
We used it at a previous internship, for an internal web system. We only compiled to js and I just once compiled some minor code to both js and C#. I can say it worked quite well and many custom widgets were made at the time. Debugging the produced js wasn't that bad either, but it sometimes didn't produce the code you wanted it to (I remember one string comparison issue in js, where the reference was being compared instead of the value). The code was deployed in production and had worked fine for years. I'm pretty sure they still use it today.
That was in 2013, I haven't used it since. One problem I did have was trying to compile code made in version 2.08 using version 2.10. It needed some minor, but non-obvious adjustments. I can't quite comment on more recent releases, but I'd be a bit careful on not breaking large pieces of code by upgrading to new versions of the compiler.
You compile, haxelib run flow run "target" in target you type for example web, and thats all, in your bin, folder you get your files, remember to configure your project.flow file acording to your target and project.
Is there any UI library that can be to build both a text user interface (ncurses) and graphical user interface (GTK? QT?) from the same source?
I know that debconf can be used with various frontends, I would like to build something similar but programmable.
The library that powers YaST independence to do ncurses, gtk and qt with one codebase provides what you are looking for, and it is not tied to YaST itself.
Actually libyui only requires the standard C++ library and phtreads (IIRC). The UI plugins require of course the respective libraries (Qt, ncurses). YaST uses libyui via a set of YCP bindings that export a YCP like API on top of libyui.
The library is a bit lowlevel (one layer below an event loop), my colleage Klaus Kämpf wrote about using it some time ago in his blog, including binding to scripting languages it using swig.
The only part that is SUSE specific is the packaging, so you would need to package it yourself. Stackoverflow did not allow me to link more than once. The code of the library is linked from Klaus blog. Replace libyui for "qt" and "ncurses" for the plugin's code.
Also google for "YaST Independence From YCP" to find a blog entry from Andreas Jäger on the subject.
you could write your program to uses ncurses, and then use PDCurses to convert it to an X11 application - as the readme advertise.
I know it because I've used it as portable curses, though I've never tested its X11 capabilities
Not exactly a library but you could consider writing a web app that degrades well to Lynx
The GoboLinux guys have created their own toolkit for python called AbsTK, they use it for their installer, which actually works really good. I have never used the toolkit myself, but the apps built with it seems solid.
There's Cursed GTK, but it seems a bit dated. I found some references to a port of Qt to ncurses called Qt Console, but it seems to have disappeared.
By using a library that targets both the text-mode and GUI environments, you have a big risk of getting stuck with the worst of both worlds.
You will be better off structuring your code using the MVC pattern, and providing separate views and controllers for each platform you target. Pushing all the logic down to the model classes has several other benefits:
The code will be easier to test because you are forced to keep the user interface out of the actual domain logic.
Your program can have user interfaces that have very little in common, e.g. a web UI, or an UI driven by speech.
You can run the program easily with no UI at all (i.e. script it) by accessing the model classes directly in the same way that the controller classes do.
I think what's used for configuring the linux kernel when compiling is dialog/cdialog/xdialog. But it's been a while since I've compiled a kernel, so my memory may be off. The most promising link I can find is this one for Xdialog.
Maybe tcl/tk would provide what you want http://www.tcl.tk/
Here's the page on interfacing with curses. There is a claim there of integration with ncurses.
http://www2.tcl.tk/2372