I am very new to rockdb and will be using the rocksdb in my application as a lookup service. Does the rockDBjava library api provided contain the database itself, I mean is it not necessary to install rocksDB database separately.
I tried running the code using library and see some files created in the db path I mentioned in code, so not sure how exactly it works and if I need to install DB separately or if the library stores data in the directory and it itself acts as database?
No, you should not need to install RocksDB separately if you already have RocksJava working. They're not very clear on stating that, but if you look at the wiki in their Git repo you'll find this:
RocksJava is structured in 3 layers:
The Java classes within the org.rocksdb package which form the
RocksJava API. Java users only directly interact with this layer.
JNI code written in C++ that provides the link between the Java API
and RocksDB.
RocksDB itself written in C++ and compiled into a native library which
is used by the JNI layer.
That third point is basically their way of saying that RocksDB itself is one of the layers of RocksJava.
I am trying to compile SQLite into a library which another application is then going to link against. I am not able to compile SQLite directly into that application for reasons which are beyond the scope of this question.
However, I need a VFS to be available which by default is not. In trying to figure out how to get this working I am trying to get the vfstrace shim to be made available to the application which is linking to SQLite. This will easily prove that it is working as I can log SQLite VFS activity from the shim and see that it is actually being used when the application calls SQLite.
How do I do this? All the examples I have found show the case of when you have a source file (such as shell.c) and you compile it, sqlite3.c and test_vfstrace.c to produce an executable. However, I do not have this luxury. I could compile sqlite.c and test_vfstrace.c and generate the libsqlite3.so library file, but there is no "main" function in which to call vfstrace_register so that the VFS is actually available. Is there some other hook for the library case where I can set this up? If no, how do I make a new VFS available?
SQLite is initialized via the sqlite3_initialize() function, which is called automatically when various functions such as sqlite3_open() are called by the user, although it is a no-op on subsequent invocations. This function in turn calls the OS specific initialization function sqlite3_os_init(). This is the function that initializes all the VFSes that are built into SQLite.
For the example VFS given, append test_vfstrace.c to the amalgamation and then put a call like this in sqlite3_os_init() right before the return statement:
vfstrace_register("trace",0,(int(*)(const char*,void*))fputs,stderr,1);
Then build the library with these modifications.
The last parameter's value of 1 will make this VFS be the default, so if you don't want trace messages printed for every SQLite operation performed via code linked the library you just created change this to 0 and explicitly specify this VFS when opening a database to trace the calls for. For instance, specify the SQLITE_USE_URI compile time option, and then pass a filename of the form: "file:database.db?vfs=unix" where "database.db" is the actual name of the file to open.
Is it possible to create a directory in lua ? If so, how ?
You may find the LuaFileSystem library useful. It has a mkdir function.
require "lfs"
lfs.mkdir("/path/to/dir")
There's a "system" call (or something like that, this is from memory) which you should be able to use to run an arbitrary program, which could include the mkdir command.
EDIT: I found my Programming in Lua book. On page 203, it mentions how you could use an
os.execute("mkdir " .. dirname)
to "fake" a directory creation command.
EDIT 2: Take note of Jonas Thiem's warning that this command can be abused if the directory name comes from an untrusted source!
You may also want to look at Lua/APR, the Apache Portable Runtime binding for Lua. The docs can be found at here
One of the reasons I use Lua is that I can write code that runs across multiple OSes. I was using LFS for some time, but have found that using Lua/APR provides a more platform-neutral library. And there are lots of other useful routines in the APR.
You can use the paths package instead. Then you can simply do:
require 'paths'
paths.mkdir('your/dir')
When using HP-UX I can use the chatr utility to report on various internal attributes of a shared library. It will also allow me to modify the internal attributes of shared libraries that I have built.
The chatr utility can report, and in some cases modify, such things as:
the run-time binding behaviour,
the embedded library path list created at build time,
whether the library is subject to run-time path lookup,
internal names,
etc., etc.
Is such a utility available for Solaris?
Edit: Freaky! Thanks to mark4o's answer below I revisited the elfdump output for a typical system .so (libm.so.2 on Sol 10). However, and here's the freaky part, I mistyped the command to enter:
elfdump libm.so.2 | moe
In an amazing stroke of serendipity, this gave me back the usage message for a utility called moe whose man page description section says:
The moe utility manifests the optimal expansion of a path-name containing reserved runtime linker tokens. These tokens can be used to define dependencies, filtees and runpaths within dynamic objects. The expansion of these tokens at runtime, provides a flexible mechanism for selecting objects and search paths that perform best on this machine.
This will help me resolve why a libm.so.2 shlib is not compatible on both of two different machines leaving my incomplete executable unable to start on one server.
For displaying the information, see the Solaris elfdump and pvs utilities. For debugging binding issues, lari and moe may also be helpful. However, these utilities do not have the ability to modify the library.
Starting with Solaris 11 (and some of the OpenSolaris & Solaris Express releases leading up to it, but not Solaris 10 or older), there is now an elfedit tool for modifying runtime paths and similar attributes.
I'd like to be able to write a .swf file that is runnable as a command line app. In other words, I would be able to create actionscript classes which can interact with stdin and stdout, and could then execute that .swf directly in the command line.
I suspect that this isn't really possible. Can anyone confirm that?
EDIT:
A couple of the answers pointed out that using Flash for command line work probably isn't the best choice. I wholeheartedly agree in most situations. The reason I am asking about this is because I want to do some AS3 code generation, and reflecting on AS3 classes within the runtime would be easier than parsing the code or walking the intermediary XML that asdoc produces. I'm doing the XML approach now in Ruby, but would love to have a cleaner solution!
YES! It actually is possible.
You can create a pure AS3 AIR project (without any application window) and run from the command line using ADL (AIR Debug Launcher).
ADL will execute your SWF and will pass whatever arguments you give it directly to your application at runtime—all from the command line! To read the arguments from AS3 just add this code to your main class:
package
{
import flash.desktop.NativeApplication;
import flash.display.Sprite;
import flash.events.InvokeEvent;
public class CmdLine extends Sprite
{
public function CmdLine()
{
NativeApplication.nativeApplication.addEventListener(
InvokeEvent.INVOKE, onInvokeEvent);
function onInvokeEvent(invocation:InvokeEvent):void {
trace(invocation.arguments);
}
}
}
}
Your main class will still extend Sprite, but you won't see any UI unless you create NativeWindow objects. If you're using Flash Builder, just create a new AIR project and rename the extension of the main .mxml file to .as (before you finish the wizard).
Here is more about ADL: Using the AIR Debug Launcher (ADL)
Also, this will be very useful: AIR application invocation and termination
You can do all your output using trace(), write files, or even write directly to stdout, as seen here.
Apparently there is the Tamarin project which aims to create an open source implementation of AS3. This page gives a little detail of compiling an AS3 script and running it from a command line.
I'm not getting a good idea of how stable Tamarin is, but it might be your best bet for now. On the other hand, I have to strongly agree with #zenazn that you would be better off long-term learning a language more designed for general purposes, but if really want to just use Actionscript, don't let anyone stop you :)
There's no way to do this with a bare SWF right now.
However, you can publish your Flash content as an AIR app. The app can then be invoked from the command line, and you can collect the arguments from the arguments property of an InvokeEvent. The basic idea looks like this:
NativeApplication.nativeApplication.addEventListener(
InvokeEvent.INVOKE, onInvoke );
// ...
function onInvoke( e:InvokeEvent ) {
var numArguments:int = e.arguments.length;
// ...
}
Note, however, that this is essentially a one-way street. You can grab the command-line arguments, but Flash still doesn't grok the idea of stdin and stdout.
Actually, there is a project that makes it possible. RedTamarin is a project that extends AS3 (technically, the Tamarin project which is the Adobe/Mozilla ECMAScript project) to have access to low-level libraries (ie. POSIX). In its current state it appears to be good for stuff like shell-scripting-like programs which is what it sounds like what you're looking for.
Give it a try:
http://code.google.com/p/redtamarin/
You can interact with stdin, stdout and stderr with redtamarin
http://code.google.com/p/redtamarin/
see examples/docs here
http://code.google.com/p/redtamarin/wiki/System#stdout
http://code.google.com/p/redtamarin/wiki/System#stderr
http://code.google.com/p/redtamarin/wiki/System#stdin
there is a difference between Flash and ActionScript 3
Flash is a runtime, AS3 is a language
I don't see why AS3 would not be a good programming language
for the command line and/or the server side
Now, redtamarin is just that, a runtime that allow you to
run your AS3 source code on the command line.
Also, depending on your needs, you can use it in different ways
to run script on the command line
$ ./redshell myscript.as
run ABC or SWF files on the command line
$ ./redshell myscript.abc
$ ./redshell myscript.swf
run an exectuable
$ ./myscript
When you will run an AS3 script it will be dynamically interpreted,
using ASC you will be able to compile this same script to an ABC file
that can also be run from the command line.
If for example you need to assemble numerous ABC files together,
you can use swfmake to merge them into SWF file and the runtime
will run that SWF file too from the command line.
Finally, if you need to bundle everything in one executable,
you can use createprojector to take your ABC or SWF file
and merge it with the runtime itself to obtain an independent
executable.
Redtamarin provide native API that cover file system access,
sockets, operating system info, etc.
Now it is possible with AIR 2.0. Check this article to start.
If you are really that inclined, you could open a local socket, and then have a helper program, running from the command-line communicate with the open SWF.
This might be a good time to learn another language. May I suggest Java?
I had a similar question recently. It took me a few days to answer it for myself, but you can create a .swf and execute it entirely from the command line.
AS3 Filesystem Hello World
You could have a look at Haxe with is very similar to AS3 and could compile NekoVM Bytecode, which could be run on the command line.
Also interesting could be HippoHX, it is a kind of framework to create desktop applications out of flash movies. (similar to AIR, but with full access to the system.)
Nope--not possible. The best you can do is a standalone app (which can be made in Flash or with a Projector version of flash player, available from the Adobe website).
And why would you want to--Flash is awesome because of the great GUI capabilities. There are plenty of other programming languages that are much better suited for the command line (Python or Ruby or, god forbid, even Perl)