Lua 5.4.0-alpha-rc1 behavior with closing methods errors

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Ryan Ford-2
I think I like <bind> or <watch> for <toclose> then you could potentially "watch" other events like _close, _change, _access or other as metamethods. Semantically, it paints an idea that you're waiting for a trigger or event while not assuming you're using it to clean up or close a resource.

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Matthew Wild
In reply to this post by Sergey Kovalev
On Mon, 24 Jun 2019, 19:49 Sergey Kovalev, <[hidden email]> wrote:
I wonder why method is named __toclose but not __noreference ?

Because it doesn't mean there is no reference, that's what __gc is for already.

The method is called when a specific variable referencing the value goes out of scope. There may be other variables still happily referencing the value.

Regards,
Matthew
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Sergey Kovalev
__unreference should call immediately when reference count to zero,
unliket __gc it is called latter then there is no way to stand more or
when explicitly call collectgarbage()

вт, 25 июн. 2019 г. в 08:24, Matthew Wild <[hidden email]>:

>
> On Mon, 24 Jun 2019, 19:49 Sergey Kovalev, <[hidden email]> wrote:
>>
>> I wonder why method is named __toclose but not __noreference ?
>
>
> Because it doesn't mean there is no reference, that's what __gc is for already.
>
> The method is called when a specific variable referencing the value goes out of scope. There may be other variables still happily referencing the value.
>
> Regards,
> Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Francisco Olarte
Sergey:

On Tue, Jun 25, 2019 at 6:25 PM Sergey Kovalev <[hidden email]> wrote:
> __unreference should call immediately when reference count to zero,
> unliket __gc it is called latter then there is no way to stand more or
> when explicitly call collectgarbage()

Lua does not work by reference count.

OTOH, <toclose> is really handy to implement your own ref-count
schemes, I'm planning to use it for that if I ever switchto 5.4.

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Sergey Kovalev
Can this code solve auto close problem https://pastebin.com/LPxHKKp8

-- helper function

function scope(self)
    local result
    self=self or {}
    self.list={}
    self.error=self.error or error
    local function auto(arg,close,msg)
        if arg then
            table.insert(self.list,{ arg=arg, fn=close or io.close })
        else
            self.error(msg or "init error",2)
        end
        return arg
    end
    if self.init then self.init(auto) end
    local ok,err=pcall(function() result=table.pack(self.body()) end)
    if self.done then self.done(ok,err) end
    for _,close in pairs(self.list) do close.fn(close.arg) end
    if not ok then self.error(err) end
    return table.unpack(result)
end

-- usage:

function test()
    local src,dst
    scope {
        init=function(auto)
            src=auto(io.open("file1.txt","w"))
            dst=auto(io.open("file2.txt","w"),function(f) print "close
file" f:close() end )
        end,
        body=function()
            src:write "hello"
            dst:write "world"
        end,
    }
end

test()

вт, 25 июн. 2019 г. в 20:31, Francisco Olarte <[hidden email]>:

>
> Sergey:
>
> On Tue, Jun 25, 2019 at 6:25 PM Sergey Kovalev <[hidden email]> wrote:
> > __unreference should call immediately when reference count to zero,
> > unliket __gc it is called latter then there is no way to stand more or
> > when explicitly call collectgarbage()
>
> Lua does not work by reference count.
>
> OTOH, <toclose> is really handy to implement your own ref-count
> schemes, I'm planning to use it for that if I ever switchto 5.4.
>
> Francisco Olarte.
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Sergey Kovalev
This code https://pastebin.com/sEK9GJ9y

вт, 25 июн. 2019 г. в 20:49, Sergey Kovalev <[hidden email]>:

>
> Can this code solve auto close problem https://pastebin.com/LPxHKKp8
>
> -- helper function
>
> function scope(self)
>     local result
>     self=self or {}
>     self.list={}
>     self.error=self.error or error
>     local function auto(arg,close,msg)
>         if arg then
>             table.insert(self.list,{ arg=arg, fn=close or io.close })
>         else
>             self.error(msg or "init error",2)
>         end
>         return arg
>     end
>     if self.init then self.init(auto) end
>     local ok,err=pcall(function() result=table.pack(self.body()) end)
>     if self.done then self.done(ok,err) end
>     for _,close in pairs(self.list) do close.fn(close.arg) end
>     if not ok then self.error(err) end
>     return table.unpack(result)
> end
>
> -- usage:
>
> function test()
>     local src,dst
>     scope {
>         init=function(auto)
>             src=auto(io.open("file1.txt","w"))
>             dst=auto(io.open("file2.txt","w"),function(f) print "close
> file" f:close() end )
>         end,
>         body=function()
>             src:write "hello"
>             dst:write "world"
>         end,
>     }
> end
>
> test()
>
> вт, 25 июн. 2019 г. в 20:31, Francisco Olarte <[hidden email]>:
> >
> > Sergey:
> >
> > On Tue, Jun 25, 2019 at 6:25 PM Sergey Kovalev <[hidden email]> wrote:
> > > __unreference should call immediately when reference count to zero,
> > > unliket __gc it is called latter then there is no way to stand more or
> > > when explicitly call collectgarbage()
> >
> > Lua does not work by reference count.
> >
> > OTOH, <toclose> is really handy to implement your own ref-count
> > schemes, I'm planning to use it for that if I ever switchto 5.4.
> >
> > Francisco Olarte.
> >

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

szbnwer@gmail.com
In reply to this post by Sergey Kovalev
hi there! :)

Sergey Kovalev:
> __unreference should call immediately when reference count to zero,
unliket __gc it is called latter then there is no way to stand more or
when explicitly call collectgarbage()

hmmm, maybe we are talking about the same here, but if not, then what
about optional refcount instead of `<toclose>`?!

that way its just a matter of an entry in the metatable, and it isnt
bound to the variable, so there is no need for the whole `<toclose>`
misery (in the sense, that it opened a large can of worms on lua-l). a
lotsa ppl use their own refcount implementations for a bunch of
things, and that have a much more wide area for its use-cases, but it
can achieve the same as `<toclose>` just as well. (if im right. :D )

i think it could be simply called to `__refcount` and it could be
`nil` or `false` for disabling it (so it will wait for the gc), a
number that would be handled internally, but ppl could also mess with
it, or a function could get it from anywhere without an argument or
set it with an argument.

actually i would be much more happy with such a feature, but whatever,
decide wisely, like u did so far now! :)

bests! :)

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Francisco Olarte
In reply to this post by Sergey Kovalev
Sergey:

On Tue, Jun 25, 2019 at 7:49 PM Sergey Kovalev <[hidden email]> wrote:
> Can this code solve auto close problem https://pastebin.com/LPxHKKp8

It can solve some problems, and introduce others ( one of them is lack
of doc for it, but I'll blame that on the situation, and it seems to
assume init/error/done and some more donot error, and gives you lot of
behaviour which may be adequate for a project but not for others ).

For a big project, writing one of these and sticking to it, may be
good. <toclose> can be used as a building block for that, and as the
final solution if appropiate, it's basically a try-with-resources,
useful for somethings, not so much for others, quite powerful, being a
built-in, if you shape your code to use it. And being a built-in it
has the potential to save you a lot of code compared to other
alternatives. It seems it could be totally emulated by using pcall
wisely, but it is simple to use and short.

The only thing I dislike is the propagation on all the line ( which I
thing has been pointed as leading to problems in some io.open examples
), and may be the constness ( which forbids me shutting down __close,
but this can be easily avoided with a mini class ) and optional
closing can easily be done by deferring <toclose> a bit, which can
also solve the io.open problem.

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Sergey Kovalev
I try to minimaize introducing new problems. This is simpler version
https://pastebin.com/fj3wXBXq

scope(function(auto)
    f1=auto(io.close){ io.open("test1.txt","w") }
    f2=auto(io.close){ io.open("test2.txt","w") }
    f3=auto(io.close){ io.open("test3.txt","r") }
    f1:write "test"
end)

вт, 25 июн. 2019 г. в 21:15, Francisco Olarte <[hidden email]>:

>
> Sergey:
>
> On Tue, Jun 25, 2019 at 7:49 PM Sergey Kovalev <[hidden email]> wrote:
> > Can this code solve auto close problem https://pastebin.com/LPxHKKp8
>
> It can solve some problems, and introduce others ( one of them is lack
> of doc for it, but I'll blame that on the situation, and it seems to
> assume init/error/done and some more donot error, and gives you lot of
> behaviour which may be adequate for a project but not for others ).
>
> For a big project, writing one of these and sticking to it, may be
> good. <toclose> can be used as a building block for that, and as the
> final solution if appropiate, it's basically a try-with-resources,
> useful for somethings, not so much for others, quite powerful, being a
> built-in, if you shape your code to use it. And being a built-in it
> has the potential to save you a lot of code compared to other
> alternatives. It seems it could be totally emulated by using pcall
> wisely, but it is simple to use and short.
>
> The only thing I dislike is the propagation on all the line ( which I
> thing has been pointed as leading to problems in some io.open examples
> ), and may be the constness ( which forbids me shutting down __close,
> but this can be easily avoided with a mini class ) and optional
> closing can easily be done by deferring <toclose> a bit, which can
> also solve the io.open problem.
>
> Francisco Olarte.
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Jim-2
In reply to this post by Jim-2
24.06.2019, 22:43, "Jim" <[hidden email]>:
>>  How about __descope? It is a word. __enscope isn't, but we could create it
>>  if we ever wanted the converse operation.
> __not(_)in(_)use ?
> __(d,g)one ?
> __dead ?

__free ?


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Jim-2
In reply to this post by szbnwer@gmail.com
25.06.2019, 20:09, "[hidden email]" <[hidden email]>:
> what about optional refcount instead of "<toclose>" ?

indeed.
i also wondered why not just have optional reference counting at
the programmer's disposal with gc still being the default ?

> that way its just a matter of an entry in the metatable, and it isnt
> bound to the variable

do you intend this to be possible only from C code or from the Lua
side aswell ?

> i think it could be simply called to `__refcount` and it could be
> `nil` or `false` for disabling it (so it will wait for the gc), a
> number that would be handled internally, but ppl could also mess with
> it, or a function could get it from anywhere without an argument or
> set it with an argument.

optional metatable entry representing a function with an optional
integer argument with default value 1 ?

> actually i would be much more happy with such a feature

agreed.
optional refcounting would not hurt, right ?


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Coda Highland
On Wed, Jun 26, 2019 at 11:48 AM Jim <[hidden email]> wrote:
> actually i would be much more happy with such a feature

agreed.
optional refcounting would not hurt, right ?

Might, actually. It adds overhead to every assignment. With <toclose> or whatever we end up calling it you gain the ability to implement it yourself in the contexts where it matters without slowing down the Lua core.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Jim-2
26.06.2019, 18:58, "Coda Highland" <[hidden email]>:
>> optional refcounting would not hurt, right ?

> Might, actually. It adds overhead to every assignment.

he suggested using a metatable method, so for this to work the
assigned value needs to have a metatable or be a table itself.
hence this does not apply to every assignment.

> /s/ Adam

BTW: using the "basic" gmail webinterface might help with avoiding
html formating in mails since it sends plain text only and i think it also
converts replies to html mails to plain text. else hit the "without formating"
button in the default gmail webinterface when composing messages,
there is no need for html in purely textual communication.


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

Gé Weijers
In reply to this post by Coda Highland

On Wed, Jun 26, 2019 at 9:58 AM Coda Highland <[hidden email]> wrote:
Might, actually. It adds overhead to every assignment. With <toclose> or whatever we end up calling it you gain the ability to implement it yourself in the contexts where it matters without slowing down the Lua core.

This overhead would be substantial, because for every assignment you'd have to check whether the value being copied (number/object reference/...) needs to have a reference count updated, adding at least one conditional jump. The same thing is true when a function exits, you can't just drop the stack frame, but you have to inspect every value. Similarly, a lot of lua_xxx routines called from C would have to add reference count checks.

The impact on performance would not be minor.


--

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

szbnwer@gmail.com
In reply to this post by Coda Highland
Jim:
> do you intend this to be possible only from C code or from the Lua
side aswell ?

as i dont use the c api, i mean there both :D


> optional metatable entry representing a function with an optional
integer argument with default value 1 ?

uhmmm i knew it wont be clear, sorry! :D

so my thought was that it should be handled internally anyway, so just
a number can be enough, but if someone is messing with the
initialization, then they can write there any number, not just 1 if it
already had other references, that way the engine will count forward
from that number, so its only about helping the engine in the
initialization, as it doesnt have to count references that already
exists, but this can lead to errors if the engine wont clean up on
garbage collection if there are no more refs remaining... so a
setter/getter is probably better with self initialization instead of
manual messing, but the basic idea is here for thinking about it...

and thx for the support! :D even if the next lua already became an
alpha, and there is no much chance to change anything, but when
anything becomes available, then its hard to undo/change it later, so
i think that my new proposal is still in the right time, just its
inconvenient, as the new stuffs were already worked out and nearly
settled...



Coda Highland:
> Might, actually. It adds overhead to every assignment. With <toclose> or whatever we end up calling it you gain the ability to implement it yourself in the contexts where it matters without slowing down the Lua core.

that sounds legit, but i think its like a matter of a checking a flag
if there is nothing to do, and i believe that the presence of
<toclose> should be checked like so, but my mental model about the
internals arent really clean so far now... (but sooner or later i will
try to dedicate some time to read more of the sources :D )


best! :)

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

szbnwer@gmail.com
Gé Weijers:

(sorry, i left here the previous mails opened for a while, and i didnt
see ur mail before i write.)

so that indeed sounds to be serious... i think if anyone would
implement only the checks but nothing more, then it could be measured
more or less, not counting the impact of the actual refcount, but that
could give an idea how much it would slow down the current codes.
otherwise i think it would be a better feature without being too much
of an alien thing, so it does worth the brain cycles anyhow.

and a wild thought just came up, that there are probably other value
related checks (dunno) that could be merged like one path is for
nothing to do and the other is to check what *are* to do. but this
idea works only well if "nothing to do" is much more general related
to "anything to do"...

12