Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: thespindoctor on April 30, 2018, 04:00:26 PM
-
Does anyone know how to include Lua Stats and or Lua Graph into Mach4?
Thanks
-
I will just program what I need for stats but would like to add graphing for Lua...
-
Any LUA compatible 5.2 module library can be placed in the Modules directory and used.
Steve
-
Hi,
I found this page which has an extensive list of libraries:
http://lua-users.org/wiki/LibrariesAndBindings (http://lua-users.org/wiki/LibrariesAndBindings)
And on that list I found:
http://plplot.sourceforge.net/ (http://plplot.sourceforge.net/)
It is a 5.0 and 5.1 library so should be good for 5.2.
Does any of that look useful?
Craig
-
Hi,
OK, I've finally got CMake and MinGW installed.
I've downloaded PLplot and built it and have it in C;\Program Files\plplot so now what?. As far as I know its all there and OK, but its not a program you can run....there's no .exe
file in it anywhere. I don't know what I was expecting but I didn't get it!.
If I understand correctly its really a library that allows me to write a program in Lua which calls on a very extensive library of functions for drawing graphs. So how do
I go about using it?
I guess I have to let Mach know that I wish to use functions from an external file. How do I do that. Do I require a module? I see a Lua function called dofile()...what does it do?
Craig
-
Usually, you would try and find pre-built binaries that will just drop into the Modules directory. But it seems that it is "campy" to not provide pre-built binaries. Like you have to be in their exclusive programmer club to be able to use the library modules. At least that is my cynical take on it. :) But you have to realize that a lot of the guys that write this stuff are unix/linux oriented and they rather hate Windows with a passion. EVERYTHING is built from source in the unix/linux world. So pre-built binaries only exist in the Windows world.
But you can build it with the development tools. But if you haven't done that, it will be a steep learning curve. However, it is not rocket science. Anyone can do it, but it WILL be like poking the proverbial knitting needle through your eardrums. That, I can promise you!
To build this stuff, you need the compiler (MinGW), the library source, any other library source that the target one depends on (if any), LUA 5.2 headers and libraries, and cmake. There is a cmake GUI that makes it a little less painful. In the world of cmake, you point to the source files, point to a build directory (usually one that you create), and "configure". Which basically generates make files for the chosen compiler. Then you have to go to the old command prompt, change into the build directory, and type "make". The make program reads the generated make file (usually called Makefile without an extension) that cmake produced and that, in turn, will produce the binaries. Cmake is all a an attempt at making the source compile-able with any compiler on any platform. But... to me, it is a huge pain in the ass.
You don't let Mach know anything other than placing the resultant LUA module DLL into the modules directory. Then you use the module in your scripts, you "require" the module.
graph = require "plplot"
If the module DLL is called plplot.dll. Then you access the functions with the graph variable.
But wait... there's more! LUA 5.2 is different than LUA 5.0 and 5.1 where modules are concerned. If the module source is not setup to compile with LUA 5.2, then you will have to "port" the source to something that is compatible with LUA 5.2 This generally involves changing the call to luaL_register() to use lua_newtable() and luaL_setfuncs() instead. Here is an example from a LUA library that I recently compiled (and had to port).
#if LUA_VERSION_NUM > 501
lua_newtable(L);
luaL_setfuncs(L, functions_tb, 0);
lua_pushvalue(L,-1);
lua_setglobal(L,LIBNAME);
#else
luaL_register(L, LIBNAME, functions_tb);
#endif
Steve
-
Hi Steve,
thanks for the knitting needle analogy....it makes me cringe.
The binaries are available for Linux and Mac but not Windows. I downloaded the source files as a zip archive which I then expanded.
I have Cmake installed so I pointed the unzipped source file to it and had it build in Program File\plplot.
The original expanded source file is a little over 100M but the files in Program File\plpot are only about 5M. When I inspect the individual files I was expecting bianary code,
but no, each file is a CMake file. I have come to the conclusion that the binaries have not in fact been created but rather a whole bunch of Cmake files which presumably
direct the complier/linker in the creation of the files. Its just that they haven't done so yet.
Then you have to go to the old command prompt, change into the build directory, and type "make".
I think this is where I am at.....I'll look a bit harder and try to replicate what you have described.
Thanks for your help....this is not Mach per se, so I really appreciate that you would take the time to help out. I like the thought of being able to attach or otherwise incoperate
some of the very wide ranging Lua compatible libraries. Whats more if I can do it so can others,,,,
Craig
-
Hi,
the knitting needle is about half way though....
I had to download GnuWin32 Make and install it. Had to put its path in the PATH variable. Thereafter at the 'make' command in the plplot directory produces a whole
bunch of files....but I don't know where they all go. The plplot directory doesn't seem to grow at all and very few new files have been added to it?
I suspect there must be a bunch of command line switches which I haven't tumble to yet.
Craig
-
Look at the Makefile and look for the target "all"
the format is:
target:dependencies
A target may include other targets as dependencies. Layer upon layer, etc...
Also, search the build directory and all child directories for *.dll.
Sometimes the modules will have more than a DLL file and have quite complex directory structures. In that case, look for an installation directory path in the Makefile. INSTALLDIR or something of the like. You can directly edit the Makefile if needed. Create a directory and point the installation directory variable to that path. Then "make install". All of the build files will be copied to the directory you created with the correct directory structure. To use them in Mach, you would copy all of those files to the Modules directory of Mach, preserving the directory structure.
Steve
-
Hi Steve,
a lot of that was above my head.
This is in the Makefile in the top directory of plplot:
# CMAKE generated file: DO NOT EDIT!
# Generated by "MinGW Makefiles" Generator, CMake Version 3.10
# Default target executed when no arguments are given to make.
default_target: all
.PHONY : default_target
# Allow only one "make -f Makefile2" at a time, but pass parallelism.
.NOTPARALLEL:
Is that what you were asking about/alluding to?
In plplot there is a folder called dll, and at the start of this excerise I thought it was empty. Now it has a number of files
of the type libqsastime.dll . Does this mean that some binaries are being generated?
There is also a folder called Bindings and in it a whole bunch of files, one for each language that binds to plplot, including one for Lua.
I'm almost certain that before the 'Make' process there were a few Cmake files and a Cmake folder in the Lua folder. After the 'Make' process
nothing seems to have changed. I changed directory to Lua and issued another 'make' command, it returned almost immediately and produced
no new binaries or any other file within itself.
Craig
-
Hi smurph,
I'm in trouble here.
I got the Cmake GUI working. I displays a long list of modules/components that can be included in the build and the destination of the code that is built.
The list includes BINDINGS_Lua and a check box. The checkbox is not checked and therefore no Lua bindings are included in the build.
If I check the box, hit <configure> the box gets unchecked again.
I have thrashed around trying to get that component to stay in the Cmake list to no avail.
I found one file CMakeCache.txt where you can manually edit the text file, I turned the BOOL associated with the Lua binding module from OFF to ON. I then
caused a 'make' instruction, but still no code resembling Lua bindings or .dll.
Is there something I'm missing, maybe a dependency issue that I'm overlooking?
Craig
-
Well... typically the configure process will show you what all is needed. You may have to check the advanced checkbox in the cmake GUI to see everything. The module documentation may also shed some light on what is needed.
I would not modify CmakeCache.txt, as it is generated. And usually, to modify a make file, you do it through the cmake interface. You CAN change them, but be aware that the next time you either configure or generate, those changes will be overwritten.
Anyway, since that checkbox goes away, I suspect it is looking for the LUA 5.2 headers and libraries. You may have to point cmake to these directories if it doesn't automatically find them in the configure process. Usually, one will "configure" and resolve all dependencies and repeat as necessary. Then "generate" the make files. If the configure process fails for some reason, it will show up in the log. And possibly highlight the areas in the config list with red.
Steve
-
Hi Steve,
I apologize, this thread is getting further and further away from Mach4, its getting to be just a general computing problem.
I have in recent times used CodeBlocks IDE and written C code for TexasInstruments micros and so broadly familiar with compiling and linking,
although it took a lot of learning and experimenting.
I now perceive that Cmake is a method of bringing all those elements and settings together to build executable code. I like the idea...but like any program you have
to learn to use it properly.
At this stage I believe that I have presented Cmake with an outline of what and how I want it built....this is its default as I downloaded it, but I in fact want something
different and have yet to work out how to apply my choices to it. Such documentation there is, is very terse and I've not had much success yet.
When the cache is reloaded all items are red. Then hit <configure> and all items are no longer highlighted. I presume therefore that they all configured successfully.
When I look in the build directory I find in the Lua binding folder for instance three files of the type Cmake..., CTest.... and Makefile in addition to a CmakeFiles
folder. I presume therefore that the necessary make instructions have been configured and generated but they are ignored when 'making'.
I had a look in the source files and in the Lua bindings folder there is a 46KB file plplotluac.i and it apprears to contain C code which I guess must be the bindings itself.
I believe therefore that the source code is available to the compiler, as to whether it knows where to find it is another question.
Anyway, Rome wasn't built in a day....
In this particular case there is no need for my to include a graph plotting module to Mach other than interest. I do perceive however that users will have application for such modules,
if not this one, then something like it and I would like to be familiar with the procedure when it arises.
Craig
-
Craig,
Well... Configure may indeed be working properly. The library looks like it have several bindings, LUA only being one of them. If configure can't find the LUA headers and libraries, it may build just the other bindings, etc... That is what I was thinking. Cmake is a good concept but I don't think it can ever be implemented perfectly. Too many pieces to the puzzle a lot of times.
That plplotluac.i file is what we call an interface definition file. The C code is generated from that .i file. Normally, it is processed by LUA itself. So you may need Lua.exe in the path. And there may be a place in the configure portion to tell it where that is. So maybe a REAL LUA installation is needed.
Steve
-
Hi Steve,
that's an interesting thought, maybe Cmake is looking for Lua on my PC but wont find it buried in Mach, and as you say the Lua embedded in Mach may not be REAL Lua
as far as Cmake is concerned.
The build as it stands has regular C, Cxx, and Fortran. Prior to me installing MinGW I had no compilers installed, my PC melted down at Christmas and much of what I had is lost.
When I <configure> in the results panel at the bottom of the Cmake screen I end up with a whole bunch of messages, mainly along the lines of 'such and such installed,
Lua OFF...' I didn't pick them as errors but rather just a report of what has actually occurred. I tried to highlight entries to see if in some way I could manipulate or expand them,
to no avail. It firms my opinion that they are just a report, the red font just gives me pause. I've taken the liberty of attaching the Cmake report as a text file.
The infuriating thing is that all the material appears to be present. There are Cmake files in the Lua bindings folder, which suggests that Cmake has correctly supplied the Makefile
instructions and yet when I issue a 'make' command they are ignored despite their presence. The one obvious location to 'turn them on' is ENABLE_Lua: BOOL and yet Cmake blithely
overrides my selection.
I have to remind myself...this is a hobby....cool it!
Craig
-
Hi Steve,
I think you may have hit the nail on the head...I found this in the top level CMakeLists.txt:
# It is a fatal error if no working C compiler is available to build
# the PLplot core C library and core C examples. All other compilers
# required by our bindings are optional in that if no working compiler
# of the kind needed is available, the associated bindings and
# examples are disabled.
enable_language(C)
The absence of a Lua compiler will cause exactly the symptom I describe, ie the <configure> process overwriting my choice to include Lua bindings on the basis that there is no Lua compiler.
I am undecided whether I should download and install a Lua compiler or if the Cmake condition would be satisfied if I pointed it to the Lua compiler embedded within Mach.
Are you aware of any differences between a 'real' Lua compiler verses the embedded version?
I have often said that a hobby is best judged by what you learn in the pursuit of it. I didn't anticipate delving into Cmake or compiler/linker setups...but I am learning.
Craig