Re: [ANN] Lua for Windows v5.1.4.18 Released

["Mark Meijer" <meijer78@...>]

2008/9/12 Javier Guerra <javier@guerrag.com>:
> On Fri, Sep 12, 2008 at 8:11 AM, Jerome Vuarand
> <jerome.vuarand@gmail.com> wrote:
>> I didn't know you were still maintaining your lua-tcc, the one linked
>> by Mark above is my "fork" (it's not really a fork but rather a
>> complete rewrite). Maybe we could merge both projects at some point.
>
> fact is i'm not.  i use it (a little), but haven't changed it a bit,
> because of the stagnancy of TCC.
>
> if the new TCC can overcome that 'single environment, from now to the
> end' [1] problem, it would warrant some redesign or our bindings.

It's been a long while indeed between the current version of TCC and
the previous one. I have no clue as to what's up with it, what's
happening in the TCC community, or whether TCC should be considered
"active" now or not. I'm not a regular user of it and I'm not at all
involved with it. All I know from the changelog on their site is that
there have been many fixes of long known bugs (including those that
were previously fixed in a fork due to lack of updates).

However, I have not encountered anything in the changelog that hints
at Javier's "single environment" issue being improved at all. So there
might be no cause for a major update of the bindings to lua, though I
can't really say. Hopefully it's possible to simply replace the old
TCC version with the new one and recompile with the bindings as-is,
without any further fuss. I don't think there have been any
significant changes in what passes for the TCC API ;)


2008/9/12 KHMan <keinhong@gmail.com>:
> [...] IMHO, tcc is for people who
> don't mind hitting a corner case and have the program blow up.

Whether the new version of TCC is enough to alleviate these concerns,
I honestly don't know. Many odd things have been fixed, but I wouldn't
know how many more odd things remain (although I believe TCC has now
completely caught up with, and gone beyond, the fork that fixed a
bunch of things that some people apparently could not live with).
Hopefully, any remaining corner cases may be a lot less significant in
our case, i.e. when using it just for simple portions of "inline C" in
a Lua app, as opposed to using it for compiling entire C projects as
if it was a regular compiler (which it admittedly is not).

In any case I think there is a lot to be said for being able to
compile bits of "inline C" from Lua scripts, and execute them
in-process. I don't know of any way to do this if not with TCC, so
that's the main reason I mentioned it here. If there are other/better
ways, that's fine too.

> So let it be optional, and if LfW still want to package it, be sure to
> disable it by default and add copious warnings.
Warnings may or may not be appropriate, I honestly can't say but it's
fine with me either way. But the way I see it, all modules are
disabled by default, and enabling any of them requires (no pun
intended) conscious choice and effort, in the general form of:
require("blah"). Seems sufficient to me.


2008/9/12 Andrew Wilson <agrwagrw@gmail.com>:
> [...] And so we can't add a lib until it's
> been built in Visual Studio 2005. Which as you can tell is quite a bit
> of  work considering how many c libraries are available for Lua.

For what it's worth, I'll surely see what I can do if/when I happen to
be fiddling around with any of 'em. Should I manage to produce any
DLL's, I will certainly share them. I'm afraid I can't promise
anything more than that, though. Is there anything I should know about
the project/compiler/linker/whatever settings to be compatible with
LfW?

Cheers