LuaRT 1.9.0

Samir · 2024-10-26T21:50:16+02:00

LuaRT, the opensource Windows programming framework for Lua, is now available as alpha 1.9.0 ! ▶️ Download it now here https://LuaRT.org/index.html#section_...

YuraM

I'm not at home right now. If I remember correctly, I saw a message saying that some process has already been started. In a previous version or an earlier version. (I think it is LuaRT 1.8.0)

YuraM

YuraM
[Login to see the link]
[Login to see the link]

Samir

I was able to reproduce the bug.
Thank you

Samir

The first warning is not an error, it reminds to close any running LuaRT application (which can prevent LuaRT to update correctly)

The second message means the installer has detected a running luaRT.exe interpreter (maybe be you should kill it using the Task Manager)

YuraM

I don't see such a process "luaRT.exe interpreter" and similar processes.

Samir

I have updated binaries for the 1.9.0 preview on GitHub.
It should install correctly now 🤞

YuraM

Will you update it for x86?

Samir

Not for now I have a problem to build x86 version with GitHub workflow, I'm working on it but can't give you an ETA.

You can't use x64 version on your computer ?

YuraM

Ok. I see.
I will use x64 version . It's just that my laptop is old.
I have bought a new computer (PC) , but I haven't bought monitor yet . )

Samir

Even if it's old it will be better to run as x64

ruby

Microsft still forbids me from downloading latest github version using Edge , but fortunately it is easy to build it using vs, just run nmake.bat and it is done. great

LuaRT 1.9.0 x86 - Windows programming framework for Lua.
Copyright (c) 2024, Samir Tine.
...

x86 ? Windows Task Manager shows that it is x64

Samir

ruby x86 ? Windows Task Manager shows that it is x64

I removed the x86 version because of a GitHub workflow problem, I'm on it

ruby

I mean that the compiled version is actually x64, but the command prompt output wrongly says that it is x86

Samir

ruby
Because the _ARCH value is defined at compile time

ruby

Samir

I do not understand this code in makefile:

!if ([cl /? 2>&1 | findstr /C:"x86" > nul] == 0)
PLATFORM=x86
!else
PLATFORM=x64
!endif

but, in batch cmd, I can check that there is no x86, only x64. why still it detect as x86?

C:\>cl /? | findstr /C:"x64"


C:\>echo %errorlevel%
0

C:\>cl /? | findstr /C:"x86"

C:\>echo %errorlevel%
1

in makefile:

core\Makefile(90): !message ━━━━━━━━━━━━━━━━━━━━  Building LuaRT $(LUART_MAJOR).$(LUART_MINOR).$(LUART_RELEASE) for $(PLATFORM)  ━━━━

but actual message is:

nmake.bat
━━━━━━━━━━━━━━━━━━━━ Building LuaRT 1.9.0 for ━━━━━━━━━━━━━━━━━━━━
▸ Building Lua 5.4.7 VM ■■■■■■■■■■■■■■■■■■■
▸ Building LuaRT core framework ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
▸ Building LuaRT toolchain ■■■■■■■■■■
▸ Building static executables ■■■■
...

so the $(PLATFORM) variable is not set?

Samir

Yes there is a bug in the msvc platform détection.
To correct this, you can set the environnement variables SDK_ARCH before using nmake :

C:\LuaRT\src\> SET SDK_ARCH=%PLATFORM%
C:\LuaRT\src\> nmake

I will update the 1.9.0 as soon as I have corrected the workflow to compile from GitHub directly

esferatec

Wouldn't it be better to replace “console.color” with “console.fgcolor”.

Samir

yes you're totally right.

esferatec

I would like to make a suggestion. Is a new "sysutils" module needed, or would the functions be better placed in the "sys" module? To be honest, I don't understand the point of the sysutils module.

Samir

As the sys module is included by default, putting this functionnalities in the same module would increase LuaRT interpreter size, hence the sysutils module (as for Delphi and python for example)

« Previous Page