I've downloaded a file (ListFunc.mexw64) containing some functions I'd like to use in my algorithm. I am using Mac OS but, it seems incompatible with OS as well as the MATLAB software itself.
Is there a way to get it to work or to see the content of the file?
A mexw64 file is compiled for Win64 systems, the equivalent extension for macOS is mexmaci64 - this file simply wasn't meant to be used on a macOS.
You should try to contact the authors of the file and ask them to recompile it for Mac, or ask for the source code and compile it yourself, according to these instructions.
Related
While I am setting up MinGW-W64 (from sourceforge) exe file (for Windows 10) for C++, it shows a message that it was not downloaded correctly. My best guess is that I have a Anaconda/Jupyter setup having MinGW-W64, and it is making all the fuss. How to set it up for both C++ (VS Code / Code lite) and Python/Jupyter/Anaconda?
Make sure you don't mix versions in environment variables like PATH.
Maybe your download was bad?
Or you may have an antivirus software preventing the installation...
You could try a standalone MinGW-w64 build from https://winlibs.com/, which doesn't requite installation - just extract the archive and point VSCode to it.
I'm currently trying to learn Assembly for x64 Windows. I tried the example code from this Intel website,
but whenever I try to compile it with the command given in the document:
ml64 hello.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:Start
I always get an
LNK1104 error
I know that it means the compiler can't find the library file, I googled the problem and quickly found that I need Visual Studio with Windows SDK, which I downloaded and installed. But still can't find a kernel32.lib or user32.lib in any files other than the Windows system files.
I tried everything and I simply can't fix it. I hope someone could help figure this out.
There is a well-known MASM32 SDK available created by hutch--. This package contains the requested libraries in a (legacy) 32-bit version.
But there is also a 64-bit update of that famous package by hutch--:
Current build of the 64 bit MASM SDK.
It should contain the .inc and .lib files you need and more...
This is the current build of the 64 bit MASM SDK. This one is a lot closer to complete and with the correct Microsoft binaries added to it, it is capable of building a wide array of application types. It can be use in 2 different ways, it should be unzipped from the root directory of the partition that it is being installed on. You can either manually add it to an installation of the MASM32 SDK OR you can install it on a partition that does not have MASM32 on it and simply rename the buildx64 directory to MASM32. Installing it on another partition is the preferred technique as QE has its menus and accessories set up for building 64 bit code.
You still need to add the Microsoft binaries which would typically be from an installation of vs2017 or from an earlier version for Win7 64. In the bin64 directory there is a file called "Microsoft_File_List.txt" which shows the files you need. The list is from the current version of Visual Studio 2017 version and if this is the version you have, use the ML64 from the "x86_amd64" directory that is 402,584 bytes in size.
In the "buildx64" directory is a batch file called "makeall.bat". This must be run to build all of the libraries and include files.
They are the gold standard of Windows assembly developing.
I have written a plugin for vanilla lua. I wish to protect this plugin, and I have heard of obfuscation. I tried XFuscator, but even after fixing line 5's logic, it doesnt work. Are there any newer, better ones floating out there?
Thanks!
If you are going to run your Lua script in the same machine you build it (I mean, same Lua version, same machine architecture), you could just compile it to bytecode using luac like this:
luac -s -o example.out example.lua
And distribute the .out file, that doesn't contain the Lua source code.
Note that Lua bytecode is platform specific (endianness, word size), and it could change in future Lua versions (in fact it already did in the past). For that reason, if you compile it, let's say, in a Intel x86-64 with Lua 5.3, you should run your generated .out only in this kind of machines or compatible ones.
I am trying to use Octave within TextMate. I have installed the appropriate bundles, and have Octave installed. I am able to run Octave from within the Terminal, but would like to run programs from within TextMate itself. When I hit Build and Run, I get an error stating that the directory I am using does not contain an Xcode project, and an attempt to build with Xcode that fails.
My files are in .m format, and I've successfully used TextMate for other programming languages. Does anyone know why I can't get it to run with Octave?
Best,
You might find this useful:
https://github.com/schoeps/matlab.tmbundle
Eddie
.m is typically used as an file extension for Objective-C source files, so it seems like TextMate interprets it accordingly. You could see if the correct bundle is used and, if neccessary, deactivate the Objective-C bundle.
I had developed a small program in netbeans using c++. I need to know how can i deploy/run the package on another linux system
Abdul Khaliq
I have seen your code, you probably missing XML files in the current folder... where the executable is located... paste then and then run as ./your-executable
I recommend that you use a makefile to recompile on your target machine which will ensure that your program is deployed properly.
You should use a makefile as suggested. I know that NetBeans can generate one, but it's been a while since I last did so. Maybe this can help: http://forums.netbeans.org/topic3071.html
Typically, once compiled, your executable will need several libraries. Chance is that those libraries will also be available on the target linux system.
Thus, you can simply copy your executable over to the other system. If you run ldd on your executable, you should see the list of libraries your executable is dynamically loading. Those libraries should be available on the target system as well.
In case your executable makes use of resources such as images and other binary files, you can use a resource system (e.g. Qt Resource System) and compile those binary files into your executable.
The easiest way to test is to do the copy, run
ldd yourExecutable
on the target system. It will tell you if you are missing any library. Install those libraries using the system package manager.
Of course, you also have the option to statically build all libraries into your executable. However, this is not recommended since it makes the executable too large and complicates matters.
What type of package is your netbeans compiler creating? deb,rpm? If you are moving the package to a different linux install you will need to use that distributions package type. Ubuntu - deb
Fedora/Redhat - rpm
etc...
I'm not sure how you change this in netbeans but I'm pretty sure it has the ability to. A google search could help you more.