I have the commercial LiveCode license.
I'm trying to install mergJSON as my first external and have looked at the lesson as well as googled all I can. I've got the Externals folder set up and now am hung up on setting up the Runtime structure. Which file goes into which folder in the Runtime folder? There is a mergJSON.bundle, .dll, .dylib, .lcext, and .so. The lesson that is referenced doesn't show a Linux folder under Runtime and it shows the files going into a Database Drivers folder. It also does not help someone new in this environment have a clue which of the 5 mergJSON files goes into which folder under Runtime.
Something as simple as a directory tree under My LiveCode would go a super long way in helping to understand how to get this product installed.
I am on OSX.
Can someone give me some pointers on getting this bundle I purchased loaded to I can use it?
The directory structure for Linux is the same as the other platforms shown in RunRev's how to but using the *.so file.
The filetypes for externals are:
Windows = *.dll
OS X = *.bundle
OS X Server = *.dylib
Linux = *.so
iOS and Android = *.lcext
This directory mirrors what you will find in the Tools/Runtime directory inside the LiveCode app package as seen here:
Related
I need to get the content of archives and then I want to uncompress the selected one - but I dont want to uncompress the archives to know what's in it. I'd like to list and uncompress at least zip and rar, but (if that's possible) I don't want to be limited to only these two.
Can you advise good npm modules or other projects to achieve this?
Here's what I came up with:
zip
I found node-zip can only unzip files, but not list archive content.
rar
The best solution seems node-rar, but I can't install it on Windows.
node-uncompress This does what it says: It's an "Command-line wrapper for uncompressing various file types." So there is again no possibility to list archive content.
Currently I try to get node-uncompress to list files and hopefully it must never run cross-platform.
Solution:
I am now using 7zip with the node module node-7z instead of trying to get every archive working on its own. The corresponding site is: https://www.npmjs.com/package/node-7z
This library uses the OS independent archive manager 7zip. On Windows 7za is used. "7za.exe (a = alone) is a standalone version of 7-Zip". I've tested it on Windows and Ubuntu and it works great.
Update:
At Windows: Somehow I just got it working by adding 7za to the Path variables - not by adding 7za.exe to the "the same directory of your package.json file." like the description says.
Update 2:
On Windows 7za, that's referred in the node-7z post, cannot handle .rar-archives. So I'm using the "casual" 7-zip instead of 7za.exe. I just renamed the commanline 7z.exe to 7za.exe and added the 7-zip folder to the Path Variables.
This is a x-post from my question listed at https://answers.oculus.com/questions/583/fbx-converter-gear-vr.html
I'm attempting to use the Oculus FBX converter tool which came bundled with the Oculus Mobile SDK for Samsung Note 4 download.
Unfortunately, FBX Converter appears to be a Windows only tool :(, so I'm attempting to run this via Parallels Desktop.
There's a readme file in the tools dir which contains some instructions for downloading the AutoDesk FBX SDK and moving to an appropriate directory. I've followed them.
Inside the tools dir I see a makefile. Windows does make? Cool, so I attempt to make:
makefile(3) : fatal error U1033: syntax error : '=' unexpected Stop.
Huh... luckily there's a Visual Studio solution here. So I open the .sln and build. Dang, looks like I have to change the Platform Toolset to v110 because I have VS2012. Try again... Ahhh man, bunch of syntax errors about unexpected identifiers in std::max. I guess I'll try and fix it - std::max - expected an identifier
Cool, build is starting and..... ugh. cannot open file libfbxsdk.lib. Wait a second, I bet it's an issue with how the .sln is pulling in it's dependencies. Yup, wrong pathing. Add an extra ../ and here we go.... nope, no dice. cannot open include file fbxsdk.h.
So that's where I am right now. All I really want to do is convert an fbx file to a .ovrscene. Is that so much to ask? Is there a better way to do this? I hope so.
oh.... looks like there's a bin dir with the FBXConvert .exe included in the download. You'll have to add a .dll, to your System32 directory. That was awesome.
I have a Python application that is currently installed following Linux Filesystem Standard Hierarchy (FHS). It is installed in:
/usr/bin/ (executable)
/usr/lib/python2.x/site-packages/{appname}/ (Python libs)
/etc/{appname}/ (conf files)
/usr/share/man/ (manual files)
Now, it is desired that a non-root user installing this application could install it without root powers and that only this user could run the app. We thought the best would be to install the app in user home directory.
We already have a .{appname} directory in user home to keep per-user configuration files, as the app installed configuration files in /etc.
I think that using the .{appname} dir to keep all application files is not a good idea, as directories pre-appended with . only keeps configuration files. Probably I'll remove the .{appname} dir, as the entire application will be installed per-user now.
2 ideas:
Create a {appname} dir and create subdirs bin, etc, lib and share/man.
Replicate Linux FHS under home and create a {app-name} subdir under lib and etc
~/bin/
~/lib/{appname}
~/share/man/
~/etc/{appname}
Which one of these is more often used and more recommended? Pros and cons of each alternative are welcome. Maybe a third option?
I've seen people recommend /home/usr/bin and /home/usr/local/bin, but I don't understand the need to include the usr here as there is no need to differentiate between essential and non-essential binaries/libraries. I'd prefer to be minimalist.
Thanks in advance.
The first option is the most common. A third option is to create (or fill out) the structure under ~/.local/ (which reflects /usr) that is already used by a number of applications for share/.
In short: This question is basically about telling Linux to load the development version of the .so file for executables in the dev directory and the installed .so file for others.
In long: Imagine a shared library, let's call it libasdf.so. And imagine the following directories:
/home/user/asdf/lib: libasdf.so
/home/user/asdf/test: ... perform_test
/opt/asdf/lib: libasdf.so
/home/user/jkl: ... use_asdf
In other words, you have a development directory for your library (/home/user/asdf) and you have an installed copy of its previous stable version (/opt/asdf) and some other programs using it (/home/user/jkl).
My question is, how can I tell Linux, to load /home/user/asdf/lib/libasdf.so when executing /home/user/asdf/test/perform_test and to load /opt/asdf/lib/libasdf.so when executing /home/user/jkl/use_asdf? Note that, even though I specify the directory by -L during link, Linux uses other methods (for example /ect/ld.so.conf and $LD_LIBRARY_PATH) to find the .so file.
The reason I need such a thing is that, of course the executables in the development directory need to link with the latest version of the library, while the other programs, would want to use the stable version.
Putting ../lib in the library path doesn't seem like a secure idea, not to mention not completely correct since you can't run the test from a different directory.
One solution I thought about is to have perform_test link with libasdf-dev.so and upon install, copy libasdf-dev.so as libasdf.so and have others link with that. This solution has one problem though. Imagine the following additional directory:
/home/user/asdf/tool: ... use_asdf_too
Which gets installed to:
/opt/asdf/bin: use_asdf_too
In my solution, it is unknown what use_asdf_too should be linked against. If linked against libasdf.so, it wouldn't work properly if invoked from the dev directory and if linked against libasdf-dev.so, it wouldn't work properly if invoked from the installed location.
What can I do? How is this managed by other people?
Installed shared objects usually don't just end with ".so". Usually they also include their soname, such as libadsf.so.42.1. The .so file for development is typically a symlink to a fully-versioned filename. The linker will look for the .so file and resolve it to the full filename, and the loader will then load the fully-versioned library instead.
I am trying to install mod_java on ubuntu.
I have installed the latest java(1.6).
I have configured freeswitch with mod_java module enabled in module.conf.xml
then when i run the make file, it says:
freeswitch_java.h:5:17: error: jni.h: No such file or directory
I have searched through the java installtion folders, but did not find any include folder or jni.h.
Can anyone help, what is being the problem here.
Thanks for reading this question.
I had the same problem. The solution was to run configure with the option --with-java:
./configure --with-java=/usr/lib/jvm/java-1.6.0-openjdk/include/
I don't know if it makes any difference but I added mod_java after building freeswitch without it. It was disabled in my initial build in module.conf.xml but afterwards I ran the above command plus:
make mod_java-install
It worked for me on ubuntu with openjdk. Are you using the Sun JDK? Maybe in the version you have dont have the include folder which has the source files. Try installing the other JDK. Or try and see of ther are some other related packages in apt that will get you the include folder.
Type this linux command to locate your jni.h file on your filesystem.
locate jni.h
you should be able to get it somewhere
in /usr/lib/java directory or some other directory
depending upon your java home.
copy paste the jni.h in src/include folder of your freeswitch src.
It will throw you some more errors for different .h files
just copy all of them to your src/include folder.
in latest freeswitch, installing through Makefile, its not possible to configure as the Makefile downloads and installs. Its possible by modifying the Makefile.in file to add the include path
mod_java_la_CPPFLAGS
-I/usr/lib/jvm/default-java/include \