similar to: [PATCH 1/1] lua: Enabling io.read() in Lua.c32 with some restrictions

Hi, This series targets automatic boot menu generation, but most of it is the Lua upgrade, because I got tired reading deprecated API docs. It's mostly a straightforward forward port of the earlier Syslinux specific changes to Lua 5.1, except that: * I chose the add a stub getenv() implementation to the COM32 API instead of #ifdefing out all the references in Lua, and * I kept oslib

From: Hung-chi Lihn <hlihn at google.com> In the current Lua.c32 DMI implementation, it is a flat table with dotted names in table entries. It also misses a number DMI sub-tables. This patch, cleans up the DMI table structure using Lua's nested table structure and adds all missing DMI sub-tables. If a DMI sub-table is not supported by the hardware (not filled), then the corresponding

--- generator/lua.ml | 22 +++++++++++++++------- generator/perl.ml | 2 +- lua/Makefile.am | 1 + 3 files changed, 17 insertions(+), 8 deletions(-) diff --git a/generator/lua.ml b/generator/lua.ml index dd6aedbe9..7cfceb152 100644 --- a/generator/lua.ml +++ b/generator/lua.ml @@ -63,6 +63,8 @@ let generate_lua_c () = #endif #endif +#include \"ignore-value.h\" + #include

Hi, I am finding that my project that previously successfully built with versions 3.5 to 4.0 is now failing to link because of missing implementation for dump(). Errors I get are: Undefined symbols for architecture x86_64: "llvm::Type::dump() const", referenced from: ravi::LuaLLVMTypes::dump() in ravi_llvmtypes.cpp.o dump_content(lua_State*) in ravi_llvmluaapi.cpp.o

lua 5.2 changed API, LUA_GLOBALSINDEX is no longer available. http://www.lua.org/manual/5.2/manual.html#8.3 Signed-off-by: Olaf Hering <olaf at aepfle.de> --- Fix is only compile tested. generator/lua.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/generator/lua.ml b/generator/lua.ml index 88748ae..7461cbd 100644 --- a/generator/lua.ml +++ b/generator/lua.ml @@

The dump() methods are only meant to be used in debuggers and are only available in debug builds of LLVM. There are often similar print() methods available though. - Matthias > On Sep 25, 2017, at 11:40 AM, Dibyendu Majumdar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > I am finding that my project that previously successfully built with > versions 3.5 to

The following changes since commit 81609df52ac52636a6d4af9249ede641620cb3a7: Centralize shift_is_held(), make it work to force the command line (2014-04-20 11:46:59 -0700) are available in the git repository at: https://github.com/wferi/syslinux progress for you to fetch changes up to 5b19c094527fde3694afab1f878c2877973f5044: lua: make kernel and initrd progress output match in

Hi Dibyendu, Are you building a Debug or Release version of the compiler? I had similar problems a few days ago when I was migrating to v5.0, and it turned out that I had calls to some of the dump routines that were not guarded by either 'DEBUG(...)' or '#ifndef NDEBUG ... #endif' and I was seeing the link failures with a Release build. These had been there since LLVM v3.1 and

Hi Matthias, On 25 September 2017 at 22:43, Matthias Braun <mbraun at apple.com> wrote: > The dump() methods are only meant to be used in debuggers and are only available in debug builds of LLVM. There are often similar print() methods available though. > I am not sure how this is the case seeing that the dump() function has been working in release builds in all the LLVM releases I

Hi Martin, On 25 September 2017 at 20:35, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Are you building a Debug or Release version of the compiler? It seems that in Release builds of LLVM 5.0 the dump() implementation is absent, although the method is available in the interface. This is plain wrong in my view. If the dump() has to be removed then it should not be present

Yes, if it is in the interface it would make more sense to have a null implementation at the very least. In my out-of-tree target, I also removed them from the interface if the build was for Release to ensure that I got compile-time errors to reveal other places I might have otherwise missed. All the best, MartinO -----Original Message----- From: Dibyendu Majumdar [mailto:mobile at

Even if luaL_error is a "no return" function for the Lua runtime, adopt also in action functions the "return" idiom recommeded for it. This also helps code analyzers in not thinking that "g" might still be null after the null check followed by luaL_error. --- generator/lua.ml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/generator/lua.ml

Hi Martin On 25 September 2017 at 21:13, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Yes, if it is in the interface it would make more sense to have a null implementation at the very least. In my out-of-tree target, I also removed them from the interface if the build was for Release to ensure that I got compile-time errors to reveal other places I might have otherwise

Ferenc Wagner <wferi at niif.hu> writes: > "H. Peter Anvin" <hpa at zytor.com> writes: > >> On 08/29/2013 04:14 AM, Ferenc Wagner wrote: >> >>> "H. Peter Anvin" <hpa at zytor.com> writes: >>> >>>> On 08/22/2013 10:20 AM, Ferenc Wagner wrote: >>>> >>>>> Now that Syslinux has ls.c32 and

"H. Peter Anvin" <hpa at zytor.com> writes: > On 08/29/2013 04:14 AM, Ferenc Wagner wrote: > >> "H. Peter Anvin" <hpa at zytor.com> writes: >> >>> On 08/22/2013 10:20 AM, Ferenc Wagner wrote: >>> >>>> Now that Syslinux has ls.c32 and lua.c32, it should be possible to build >>>> a customizable boot menu in

From: Paul Emmerich <p.emmerich at first-colo.net> Hi, the new API for initramfs and files in master lacked the ability to build initramfs objects from files loaded via HTTP/TFTP in Lua. The documentation indicated that it should be possible (and I believe I did that in an older version). I implemented a few new functions to handle files/initramfs objects better. Changes: * NEW:

On 22 February 2015 at 22:54, Hal Finkel <hfinkel at anl.gov> wrote: >> I tried setting the module's DataLayout to the engine's DataLayout. >> Don't see any improvement. >> The memcpy() is to perform a struct assign, so I tried replacing that >> with member by member store. >> But even then the loads are not being eliminated so I guess the >>

Greetings All. We wanted to be able to parse the DHCP values and options and write a lua script based on the information found. We are also using the CPU flags, but thankfully in at least version 4.04 there is already some CPU value parsing even if it isn't documented. Using the information from the CPU table we wanted to be able to choose the kernel to boot. Using the DHCP table

This is a possible implementation for syslinux.initramfs_add_file() for the lua.c32 module, it adds a third parameter not documented, the dst_filename as it is required for placing the new file in the initramfs: ########################################################### --- syslinux.orig/com32/lua/src/syslinux.c 2011-03-29 16:52:37.161106252 -0300 +++ syslinux/com32/lua/src/syslinux.c 2011-03-29

Hi, Any word on this request? I'm planning to add error handling (as bailing out after printing "failed") to sl_boot_linux(). Shall I build on this patch, or shall I squash them together? Thanks, Feri. Ferenc Wagner <wferi at niif.hu> writes: > The following changes since commit 81609df52ac52636a6d4af9249ede641620cb3a7: > > Centralize shift_is_held(), make it