Migrating old Addons to NAPI - node.js-addon

I'm new to Node.js addons, I don't understand the difference between nan and n-api.
And is there an easy way to migrate an addon for old version (node v.0) to a newer version (node v.8)?

n-api is a new way to create addon independent from the underlying JavaScript runtime (ex V8) and is maintained as part of Node.js.
I think there is no easy way for migration to n-api because it changed almost every interface but I think programming with n-api is easier than nan. In n-api you can use pure C programming and it's new feature. for more example on n-api you can check here.

Related

Is the idaperl plugin no longer developed?

I am a student studying reverse engineering
I mainly use C and Perl, and I think this is a good choice
However, python is still being developed for ida, but idaperl says development has been discontinued (github). I have two questions.
Has idaperl development stopped?
github supports ida 6.5. Can this be used informally in 7.0?
The repo README.md says it's been discontinued,
note: I am not actively developping this plugin anymore, since i myself now mostly use idapython for scripting.
I have been looking for active forks, but there seems to be none. So your best bet might effectively to use IDAPython. It's anyone's guess whether this version supports 7.0, but you might want to downgrade to 6.5 if you effectively want to use that. There seem to be some tools that support reverse engineering in CPAN; depending on what you want to do, one of them might be useful if you're keen on using Perl.

Tutorial on Firebird 3.0 UDFs / External Functions

Just wanted to know if anyone knows of a tutorial on how to create a udf specifically for FB3 or if the process is pretty much the same as FB2.5.
I've been looking online but only can find details for FB2 and I wanted to make sure i wasn't missing anything new that might be available.
As well, is there a way to build UDFs with c# or do I need to do these with either c++ or Delphi?
Any direction would be great, thanks!
Classic UDFs are the same in Firebird 2 or 2.5 and 3. So any tutorial you'll find is going to work. These UDFs need to be written in native code, so C++, Delphi, etc.
Firebird 3 also adds new type of UDFs called UDR. These are again written in native code, but the interface between Firebird and your code is slightly different. Refreshed.
And finally, thanks to the plugin architecture of Firebird 3, you can write the "UDFs" in C# as well. I wrote a plugin FbNetExternalEngine that does the heavy lifting from native code to .NET/managed world. With that you can write the code in .NET language and call it from SQL the same way the UDFs/UDRs are called. (The v1-final should be available soon.)

Is GEF4 mature enough?

I am familiar to GEF3. GEF4 has a better architecture.
And I have to make decision whether using GEF3 or GEF4 MVC for our project.
My question is: Currently, is GEF4 mature (e.g full editing features like GEF3, documents, API's stability) enough? Or should I use GEF3 instead?
Thanks
Personally, I would say since the GEF 4.0.0 release that bundled GEF4 1.0.0 the framework is quite stable (API-wise). However, some support for common functionality is still lacking, which you would need to implement yourself (e.g. direct editing). If you are still unsure, you can implement a prototype with GEF to see if it fits. If you run into any problems, the GEF forum is a nice place to get help.

Does PostgreSQL support PMML

I couldn't find any reference that PostgreSQL db supports PMML using a search engine. I was wondering if anyone had any luck with this. I would like to deploy a Random Forest model that is built in R in PostgreSQL (I'm aware of other work arounds - but want to get an answer for this question before I go down the other route).
From my own reading, PostgreSQL doesn't directly support PMML, however if you use JPMML it integrates seamlessly with PostgreSQL. Its library is opensource and extensive.
https://github.com/jpmml/jpmml-postgresql
There is no built-in support. However with the XML support, the extensible stored procedure language handlers, and such it shouldn't be too hard to implement as an add-on (or perhaps an extension).
I don't foresee PMML support coming built into PostgreSQL in the near to moderate future so you would do best to either implement it yourself or go another route.

What library should I use for accessing Riak from Scala?

For a project I'm using both Scala and Riak (two things I have never worked with before ;) ).
Google searches seem to suggest using Riakki. However, it seems like that particular library hasn't been maintained since 2009 and doesn't even compile on my system. There is a more up-to-date fork on GitHub that does seem to work with more recent Scala versions. But Riakki seems to depend on Jiak, which has been deprecated since february of last year.
Seems like the only reasonable choice would be to use the official Riak Java-library from Scala. That's certainly possible, but I'd like to do things the Scala-way as I'm trying to learn the language. Having to interface with a Java-style API might ruin a bit of the fun. Writing my own wrapper sounds like it will be too much work.
tl;dr: I want to use Riak from Scala. What are other people using?
edit: just found Ryu (can't link to it - annoying limit on amount of hyperlinks per question for new users). Doesn't seem all that mature though.
Stackmob recently opensourced Scalariak.
Scaliak is a scala-ified version of the High-Level Riak Java Client w/
a Functional Twist. It is currently being used in production at
StackMob.
Scaliak is currently feature incomplete vs. the original High-Level
Riak Java Client. What is currently supported are mostly features
being used in production (there have been a few features implemented
and subsequently not used).
There is also Raiku which states that it is async.
I'm in the same bucket - excuse the bad pun - although I have some experience with Scala. I'm thinking of using the official Java client.
When you are toiling up a steep learning curve, you don't need to be dealing with incomplete and potentially wobbly API's. In my experience, using Java API's from Scala is minimally painful.
I think there'll be enough delight in playing with our new Raik toy that we'll forget about whatever un-Scala-ish foibles the Java API inflicts upon us. All the best.
I'm the author of yet another Scala Riak client, simply called riak-scala-client. It is based on Akka and Spray, it is not built on top of the existing Java client, and most importantly it is completely non-blocking.
Check it out at http://riak.scalapenos.com and let me know what you think.