I'm quite new to using electron and I'm having a problem that seems to be to do with the setInterval() function. I'm importing a library named exiftool-vendored which in turn depends on a library named batch-cluster.
Batch cluster is crashing when I import it because it expects a return value from setInterval() of class Timeout which is what the node implementation returns. Instead it returns an integer which is what chrome returns. See the docs here for the two different implementations:
https://nodejs.org/api/timers.html
https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setInterval
So I have a few questions in regard to this
Is the problem what I think it is?
How would I solve it? I'm thinking of forking the batch-cluster library, is there a better solution that doesn't require this?
Does this happen often in Electron? Are there functions defined in both Node and Chrome which have the same name but behave differently?
Thanks for taking the time to look at my question!
Josh
It's not a great idea to do long running tasks in the Electron main process, it can cause lots of issues.
I submitted a PR to batch-cluster which should fix the issues when it makes it into exiftool-vendored.
Related
I have a program and I want that program to work for several users, with different passwords. How can I solve this problem with using node js?
I use instagram-private-api and want to login multiple accounts.
I think you are missing the point of node js. The reason why many other languages use threading (C#, java, c++, etc) is because all the code written is synchronous. Rather, it executes line by line. Line 10 doesn't execute until line 9 finishes. However, this is not to say they don't have asynchronous implementations. These days there are ways to write asynchronous syntax in those languages, but generally speaking, they're mostly all synchronous.
Enter javascript and the nodejs platform. 95% of it is asynchronous (95% is a total guess and more of a figure of speech, but there are "synchronous" functions... which should be used very rarely and, generally just avoided). So node uses a "single thread", but operates around something called an event loop. Not going to go into details about that here, but you can google on what the event loop is and how it works... other folks will explain it better than I can. Thus, because of that design, and because of the asynchronous nature, you really don't need threading in your nodejs application.
Sounds like you need to just go get your feet wet with node. Take some tutorials, etc. It's quite trivial to handle multiple users at once, and no threading is necessary.
Also, if none of that makes sense, then also go read up on "synchronous vs asynchronous".
Node js is a single threaded language but has asynchronous functions. For example if we use a loop in node js then as node js is single threaded then nothing can be executed until that loop finishes but this is not the case. We can use async functions which will run in event loop side by side with the main thread.
So I've recently started using Typescript. Both for the back end (nodejs) and front end, and I'm started to feel an urge to chew on my own arm every time I have to add a new import.
Coming from the .NET world the last 15 years I've come to appreciate the more or less automatic type resolving. Especially with a background in C/C++, which whenever I return to, remind me of the #include hell that ever so often becomes the case. Given what I am now facing, I get a feeling of "those were the days".
I typically prefer to keep my code as one class -> one file (with some obv exceptions for smaller stuff). This results in a lot of files and even more imports. I recently discovered some tools that help out creating the imports but it is still really annoying.
I get it that the underlying JS needs these imports (in various ways depending on module system) But given how easy these tools resolves the imports. Would it not be possible for the compiler to simply generate them? In the rare case of ambiguity the compiler would simple give an error and the user needs to resolve it manually.
Typescript seems to be a great language otherwise but this is really close to a deal breaker for me. Or am I missing something? Can this be done in a better way?
In 0.7.0, "Experimenetal isolates support" [sic] was introduced. I never understood this besides some vague idea that they gave threading-like capabilities but without the problems of threads. And maybe were good for solving Node's debugging/error handling story.
But, nobody ever explained what they were, either in that blog, or in the first few Google results. What are isolates? Why were they introduced to Node?
This morning, a bunch of GitHub issues (2662, 2663, 2665, and probably more) were closed with the comment "isolates is dead". What happened? Why did this supposedly good idea, which from what I could tell was the headline feature for 0.7, die?
Explained here: http://groups.google.com/group/nodejs/msg/6b8b8a487d2ab817
Ben just scooped me before I could get the message sent :)
Just in case the link #isaacs postet ever breaks, here the contents:
The Isolates feature was intended to make it possible to run
child_process.fork() in a thread, rather than a full process. The
justification was to make it cheaper to spin up new child node
instances, as well as allowing for fast message-passing using shared
memory in binary addons, while retaining the semantics of node's
child_process implementation by keeping them in completely isolated v8
instances.
It was a very informative experiment, but has ultimately turned out to
cause too much instability in node's internal functionality to justify
continuing with it at this time. It requires a lot of complexity to
be added to libuv and node, and isn't likely to yield enough gains to
be worth the investment.
We're going to roll back the changes in master that were added to
support Isolates, and instead focus on Domains and other things that
promise to increase stability and make debugging easier. This change
will land in 0.7.3. It's entirely possible that we may decide to use
v8 isolates in some future version of node, but they will not be in
0.8.
If you were eagerly looking forward to using this feature, and find
yourself shocked or frustrated by this decision, please contact me
directly. It's not our intention to leave anyone stuck, and I do
understand that this feature was promised for some time. If this
causes hardship for you, let's figure out another way to get your use
cases handled.
It's never easy to back-pedal, but doing experimental things means
sometimes finding out that you were headed in the wrong direction. The
sooner we make this change, the easier it will be.
Thanks.
You can think of Isolate as an independent instance of V8 runtime. It has own memory management (GC). The name comes from Chrome execution engine where you have multiple tabs and each tab has own JavaScript environment engine. Each tab (and JS environment) has to be 'isolated' from each other, so none of the page can access another page environment (window.local or window.document). That is the reason why V8 has Isolate object, which allows it to run in parallel multiple environments (pages/tabs) independent (isolated) from each other.
At http://nodejs.org/#about it says the following:
"Node is similar in design to and
influenced by systems like Ruby's
Event Machine or Python's Twisted.
Node takes the event model a bit
further—it presents the event loop as
a language construct instead of as a
library."
Are there other frameworks or languages that likewise expose the event loop?
Tcl has had this capability all along (last 2 decades). See http://www.tcl.tk/about/netserver.html
This is not to say Tcl does -- or should do -- everything Javascript and/or node.js does. But it is a valid answer to the question as to what "other frameworks or languages ... likewise expose the event loop?"
To be honest, I don't think there is something that's comparable to Node.js at the moment.
Why? Well basically because of the fact that JavaScript was single threaded from the start off, this made the language evolve in what it is today, a language that's perfectly fit for asynchronous programming, like you do it in Node.js.
Functions being first class objects, as well as having closures is a must if you want a Node like experience. For example you could just as well wrap plain C around the event lib and use that. But how much fun would that be? Even with twisted, you don't get even near the Node.js experience.
Second point is that Node.js has - except for the sync functions of the fs modules - no blocking functions, so while you can certainly do this style of programming in Python, you never know for sure if that library call isn't going to block your whole program. And kill the throughput of your server.
Also Node is fast, like in REALLY fast. V8 is definitely way ahead of Python and Ruby, yes you can write C-Extensions for both, but you can just as well do that for Node.js. Another plus point of using V8, Google is investing a ton of time/money into that Engine, another up to 2x improvement is already on the way with Crankshaft.
Node.js has more plus points, it's a complete framework (while Twisted is mainly async networking) and it's JavaScript.
The latter one may sound stupid, but the ability to re-use code and not having to do context switching , as well as being able to use mature frameworks for DOM manipulation (well, that is as soon as jsom gets into a more stable state) is another killer feature.
If you haven't done yet, I recommend you watch a couple of the talks listed on our Tag Wiki.
Especially the YUI one shows what possibilities await us in the near future.
So to sum it all up:
Although there are quite some frameworks out there that have an event loop, just having the loop itself won't give you the same experience as Node.js, so you should not expect a comparable experience when doing stuff in C or Java for example.
For the java platform I guess you could compare netty to node.js
I've been playing around with node.js (nodejs) for the past few day and it is fantastic. As far as I can tell, lua doesn't have a similar integration of libev and libio which let's one avoid almost any blocking calls and interact with the network and the filesystem in an asynchronous manner.
I'm slowly porting my java implementation to nodejs, but I'm shocked that luajit is much faster than v8 JavaScript AND uses far less memory!
I imagine writing my server in such an environment (very fast and responsive, very low memory usage, very expressive) will improve my project immensly.
Being new to lua, I'm just not sure if such a thing exists. I'll appreciate any pointers.
Thanks
A recent corresponding project is Luvit "(Lua + libUV + jIT = pure awesomesauce)".
From the announcement:
this is basically luajit2 + libuv (the event loop library behind
nodejs). It compiles as a single executable just like nodejs and can
run .lua files. What makes it different from the stock luajit
distribution is it has several built-in modules added and some
slightly different semantics.
Notice that we're not running as a CGI script to apache or anything
like that. The lua script is the http server. You get your
callback called every time an http request is made to the server.
Looks like the following is exactly what I was looking for:
LuaNode https://github.com/ignacio/LuaNode
See lualibevent and lua-ev and also Lua Gem #27
You might also have a look at luv:
https://github.com/richardhundt/luv
from the lua mailing list:
How does luv relate to Luvit - LuaJIT + libuv (Node.js:s/JavaScript/Lua/)?
It doesn't really. Luvit borrows heavily from node.js's architecture
(reactor callbacks, etc.), links statically against luajit, provides
it's own module system and executable. Luv is just a Lua module which
binds to libuv. The key difference is that Luv is more like an m-n
threading engine combining coroutines and OS threads while using the
libuv event loop under the hood.
So other than the fact that they both bind to libuv, they don't have
much in common.
You might want to take a look at Luvit or a gander at the Lua Github site. I think it takes the approach of implementing Node.js functionality right inside Lua. You write Lua code on the client side and on the server side. Here is a description of Luvit approach to doing Node.js functionality in Lua.
if i understood the question right, take a look at http://openresty.com/
luvit aims to be to Lua exactly what Node.js is to Javascript. Definitely a promising project.
You can get node.js style non-blocking IO with lua-handlers.
It even has an async. HTTP Client, which makes it really easy to start parallel HTTP requests. See the test_http_client.lua file as a example of the HTTP client interface.
You should also check out Lapis. It's a very lightweight and fast framework for OpenResty: http://leafo.net/lapis/
I've really been enjoying it and predict it will have a bright future!
As you would expect with anything built to leverage OpenResty, it's benchmarks are insanely good: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=query
The author of Lapis also wrote a CoffeeScript-like language for Lua called MoonScript which is quite nice:
http://moonscript.org/