lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi Simon,

On 9 December 2015 at 02:31, Simon Cozens <> wrote:
>> Does SILE create a lot of Lua functions dynamically?
> No, but it does call the same very small functions hundreds of thousands
> of times. The most complex routines are in here:

I had a quick look at above. Sadly with code that is frequently
accesses deeply nested table structures is not very well handled in
Ravi - currently thee is no easy way to detect types when using such

>> I'd be interested to know what auto options you tried out.
> I just did

Thanks - that's good to know. If I get some time I will try running SILE myself.

>> So for best results the compiler needs to be helped by annotating
>> types.
> Ah. It's a shame there isn't a backward compatible way to do this. :(
> Could we not have a ravi.annotate() function which could be initialized
> to a dummy function in plain Lua?
> Also, I guess another problem is that SILE makes heavy use of objects -
> table elements rather than plain variables - and I can't see a way to
> annotate table members. i.e. I would like to be able to do:
> _length = std.object {
>   length : number = 0,
>   stretch : number = 0,
>   shrink : number = 0,
> }
> I've tried doing a few annotations, but without being able to annotate
> table members it all goes wrong quite quickly. e.g.:
>   local pi:integer
>   ...
>   pi = n.penalty or 0
> core/break.lua:101: Invalid assignment: integer expected near 'end'
> Actually n.penalty is an integer, but I can't annotate it as such.

Yes heavy use of tables as objects is problematic for Ravi as there is
no way to determine types when such constructs are used. I am looking
at a possible solution (see the thread but this is
not done yet.

>> Each Lua function goes into its own module (compilation unit) in LLVM
>> at present - this makes each function autonomous and therefore garbage
>> collectible - but this is not optimum usage of memory. I need to work
>> on putting multiple functions in a module; but this would mean that
>> the module cannot be collected until all functions in it are
>> collected.
> It would be helpful to be able to declare a bunch of functions as
> related. I tend to put related functions in a table for this purpose,
> and that's a pretty common object oriented programming style. So you
> might have a way to compile a table full of functions as a unit.

Thank you for the suggestion; I was thinking of the same thing after
getting your initial report.