Source code repository?

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

Source code repository?

David Favro
Hello,

Is there any access to the Lua source code repository?  I've been all over
the website but I can't seem to find it, and I hate working on stale
released code, I don't want to start working on something that someone else
has already done.  For example, should I notice a bug in 5.2-alpha, I would
like to find out if it has been fixed already in the latest code, or if I
should further pursue it.  If I tracked it down in the released 5.2-alpha
code, I might be wasting my time.

Thanks,
David Favro

Reply | Threaded
Open this post in threaded view
|

Re: Source code repository?

Jim Whitehead II
On Tue, Jan 18, 2011 at 4:52 PM, David Favro <[hidden email]> wrote:
> Hello,
>
> Is there any access to the Lua source code repository?  I've been all over
> the website but I can't seem to find it, and I hate working on stale
> released code, I don't want to start working on something that someone else
> has already done.  For example, should I notice a bug in 5.2-alpha, I would
> like to find out if it has been fixed already in the latest code, or if I
> should further pursue it.  If I tracked it down in the released 5.2-alpha
> code, I might be wasting my time.

Lua is open source, but not open development. There is no public
repository that contains anything other than what the authors have
released as alpha/beta/rc versions.

- Jim

Reply | Threaded
Open this post in threaded view
|

Re: Source code repository?

David Favro
What a pity.  I've found and already fixed a bug in 5.2 alpha, but I'm not
inclined to send it upstream to people who've no interest in my
contribution.  Perhaps they will independently discover and fix it prior to
the final release.  Is there at least some bug-tracking database where I
could see if they're aware of it before I waste even more of my time fixing
other bugs that are perhaps already fixed?

On 01/18/2011 11:54 AM, Jim Whitehead II wrote:

> On Tue, Jan 18, 2011 at 4:52 PM, David Favro <[hidden email]> wrote:
>> Hello,
>>
>> Is there any access to the Lua source code repository?  I've been all over
>> the website but I can't seem to find it, and I hate working on stale
>> released code, I don't want to start working on something that someone else
>> has already done.  For example, should I notice a bug in 5.2-alpha, I would
>> like to find out if it has been fixed already in the latest code, or if I
>> should further pursue it.  If I tracked it down in the released 5.2-alpha
>> code, I might be wasting my time.
>
> Lua is open source, but not open development. There is no public
> repository that contains anything other than what the authors have
> released as alpha/beta/rc versions.
>
> - Jim

Reply | Threaded
Open this post in threaded view
|

Re: Source code repository?

Marc Balmer
Am 18.01.11 18:05, schrieb David Favro:
> What a pity.  I've found and already fixed a bug in 5.2 alpha, but I'm not
> inclined to send it upstream to people who've no interest in my
> contribution.  Perhaps they will independently discover and fix it prior to
> the final release.  Is there at least some bug-tracking database where I
> could see if they're aware of it before I waste even more of my time fixing
> other bugs that are perhaps already fixed?

Why don't you just post your patch on this mailing list?  It will be
seen by the right people.

>
> On 01/18/2011 11:54 AM, Jim Whitehead II wrote:
>> On Tue, Jan 18, 2011 at 4:52 PM, David Favro <[hidden email]> wrote:
>>> Hello,
>>>
>>> Is there any access to the Lua source code repository?  I've been all over
>>> the website but I can't seem to find it, and I hate working on stale
>>> released code, I don't want to start working on something that someone else
>>> has already done.  For example, should I notice a bug in 5.2-alpha, I would
>>> like to find out if it has been fixed already in the latest code, or if I
>>> should further pursue it.  If I tracked it down in the released 5.2-alpha
>>> code, I might be wasting my time.
>>
>> Lua is open source, but not open development. There is no public
>> repository that contains anything other than what the authors have
>> released as alpha/beta/rc versions.
>>
>> - Jim
>


Reply | Threaded
Open this post in threaded view
|

Re: Source code repository?

steve donovan
In reply to this post by David Favro
On Tue, Jan 18, 2011 at 7:05 PM, David Favro <[hidden email]> wrote:
> What a pity.  I've found and already fixed a bug in 5.2 alpha, but I'm not
> inclined to send it upstream to people who've no interest in my
> contribution.

The Lua authors are always grateful for bug reports and fixes, and
this list has been the way the process is managed. So I'd suggest,
post a diff and problem statement.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Source code repository?

Jim Whitehead II
In reply to this post by David Favro
On Tue, Jan 18, 2011 at 5:05 PM, David Favro <[hidden email]> wrote:
> What a pity.  I've found and already fixed a bug in 5.2 alpha, but I'm not
> inclined to send it upstream to people who've no interest in my
> contribution.  Perhaps they will independently discover and fix it prior to
> the final release.  Is there at least some bug-tracking database where I
> could see if they're aware of it before I waste even more of my time fixing
> other bugs that are perhaps already fixed?

I apologize if my response somehow suggested that the Lua authors were
not interested in discussion regarding the language, the development
of the language, and bugfixes in particular. My response was somewhat
terse given that a simple Google search shows the question is in the
FAQ on lua.org:

http://www.lua.org/faq.html#1.8

The explanation given there is much better than mine.

There is no reason for you to not report the bug that you have
encountered, and provide information about how you have resolved it.
The FAQ also addresses this:

http://www.lua.org/faq.html#1.9

Hope that helps,

- Jim

> On 01/18/2011 11:54 AM, Jim Whitehead II wrote:
>> On Tue, Jan 18, 2011 at 4:52 PM, David Favro <[hidden email]> wrote:
>>> Hello,
>>>
>>> Is there any access to the Lua source code repository?  I've been all over
>>> the website but I can't seem to find it, and I hate working on stale
>>> released code, I don't want to start working on something that someone else
>>> has already done.  For example, should I notice a bug in 5.2-alpha, I would
>>> like to find out if it has been fixed already in the latest code, or if I
>>> should further pursue it.  If I tracked it down in the released 5.2-alpha
>>> code, I might be wasting my time.
>>
>> Lua is open source, but not open development. There is no public
>> repository that contains anything other than what the authors have
>> released as alpha/beta/rc versions.
>>
>> - Jim
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Source code repository?

Luiz Henrique de Figueiredo
In reply to this post by David Favro
> Is there any access to the Lua source code repository?

http://www.lua.org/faq.html#1.8

Reply | Threaded
Open this post in threaded view
|

Re: Source code repository?

Luiz Henrique de Figueiredo
In reply to this post by David Favro
> I've found and already fixed a bug in 5.2 alpha, but I'm not inclined
> to send it upstream to people who've no interest in my contribution.

We're definitely interested in any bugs found in 5.2 alpha.
Please report here. Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Source code repository?

David Favro
In reply to this post by Jim Whitehead II
On 01/18/2011 12:10 PM, Jim Whitehead II wrote:
> I apologize if my response somehow suggested that the Lua authors were
> not interested in discussion regarding the language, the development
> of the language, and bugfixes in particular.

Your response did not directly say it; rather it was my inference that
authors who do not provide access to the current state of the code, or at
least a list of bugs of which they are aware, are not interested in outside
contributions.  I have wasted too much of my life working on stale code: in
many cases I end up fixing a bug that had already been fixed, etc.  Of
course sometimes this is inevitable, but deliberately avoiding providing the
latest version makes it far more likely and is a bit of a slap in the face
to potential contributors.  I think that all of us can agree that our time
is limited and valuable, and we only have so many keystrokes to make before
we die.  I try to respect others' time by not needlessly wasting it, and I
appreciate it when others show the same respect for mine.  Please forgive me
if I seem sensitive on this issue, but it has happened much more than once.

As a coder, I often don't differentiate much between reporting a bug, and
fixing it.  I try hard not to report bugs that I am not certain exist and
are well-defined (because I don't like _getting_ bug reports that aren't
well-defined), and very often this is most easily accomplished by examining
the code rather than "reverse engineering" what conditions produce the
errant behavior.  This often means that most of the effort is expended in
finding and quantifying the problem while the fix may be just a simple
change to one line of code, so I am more likely to report a bug as its fix
than as a set of test cases... but in either case, whether producing a solid
description or fix of a bug -- one that doesn't waste the authors' time --
is a lot of work, and working with old code makes it likely that sometimes
that work, on the part of the reporter, will be wasted.

Not providing read-only access to the repo, or at least regular snapshots of
the latest code seems to me to show that lack of respect, and with what
advantage?  The authors can still retain absolute power over the code -- it
will be released someday anyhow, what is lost by just letting others see it
now?  Nothing in the comments to which you linked seems to offer an
explanation for this.  It did say that "we can provide a current snapshot,"
but whatever 'provide' means, it's clearly not as available as just posting
it on the web.  At the very least, why is there not, on the download page,
or especially the page where the link to the alpha-code is, a comment
saying, "email here to get the latest snapshot"?

At any rate, I will post the patch to the list this time.

> My response was somewhat
> terse given that a simple Google search shows the question is in the
> FAQ on lua.org:
>
> http://www.lua.org/faq.html#1.8
Thanks for the link; while I didn't use Google, I did spend some time
perusing the web-site before posting; I guess I must have missed those
entries because I expected a more prominent notice.

-- David Favro

Reply | Threaded
Open this post in threaded view
|

Re: Source code repository?

Luiz Henrique de Figueiredo
> or at least a list of bugs of which they are aware

http://www.lua.org/bugs.html
http://www.lua.org/faq.html#2.3

Reply | Threaded
Open this post in threaded view
|

PATCH: file:close() return-value for pipes

David Favro
In reply to this post by David Favro
This is really two changes, one which fixes the just-plain-wrong behavior of
the return-value of file:close() when called on a pipe on Linux (and
presumably also other posix platforms) [this is the more important of the
two], and the addition of a second return-value to the API, indicating the
type of exit of the child process.  I wrapped the two into the same patch as
I consider them to be tightly related.

Test case to follow.


0001-file-close-return-value-is-consistent-with-the-manua.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: file:close() return-value for pipes

David Favro
This is admittedly not a pretty test case but it illustrates the problem if
it, and its output, are examined.  Included below are the output of several
runs, the expected output being the third, "Patched 5.2".

Unpatched 5.1:
    lua test-popen.lua
    Lua version: Lua 5.1
    sh: foobarbaz: not found
    cmd: foobarbaz
      rc: true
      etype: nil
    cmd: cat>/dev/null
      rc: true
      etype: nil
    cmd: exit 3
      rc: true
      etype: nil

Unpatched 5.2:
    lua test-popen.lua
    Lua version: Lua 5.2
    sh: foobarbaz: not found
    cmd: foobarbaz
      rc: 32512
      etype: nil
    cmd: cat>/dev/null
      rc: 0
      etype: nil
    cmd: exit 3
      rc: 768
      etype: nil

Patched 5.2:
    lua test-popen.lua
    Lua version: Lua 5.2
    sh: foobarbaz: not found
    cmd: foobarbaz
      rc: 127
      etype: e
    cmd: cat>/dev/null
      rc: 0
      etype: e
    cmd: exit 3
      rc: 3
      etype: e


test-popen.lua (775 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: file:close() return-value for pipes

Luiz Henrique de Figueiredo
In reply to this post by David Favro
> This is really two changes, one which fixes the just-plain-wrong behavior of
> the return-value of file:close() when called on a pipe on Linux (and
> presumably also other posix platforms)

Thanks for your patch but Lua targets ANSI C platforms not POSIX.
We prefer to avoid #ifdefs in the main code.

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: file:close() return-value for pipes

David Favro
On 01/19/2011 06:22 AM, Luiz Henrique de Figueiredo wrote:
>> This is really two changes, one which fixes the just-plain-wrong behavior of
>> the return-value of file:close() when called on a pipe on Linux (and
>> presumably also other posix platforms)
>
> Thanks for your patch but Lua targets ANSI C platforms not POSIX.
> We prefer to avoid #ifdefs in the main code.

I'm not sure what ANSI C describes for the return-value of pclose(), but
your own manual says that the return-value of file:close() will be the exit
status of the child process; your own code returns something other than
that.  That's the definition of a bug.

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: file:close() return-value for pipes

David Favro
In reply to this post by Luiz Henrique de Figueiredo
On 01/19/2011 06:22 AM, Luiz Henrique de Figueiredo wrote:
>> This is really two changes, one which fixes the just-plain-wrong behavior of
>> the return-value of file:close() when called on a pipe on Linux (and
>> presumably also other posix platforms)
>
> Thanks for your patch but Lua targets ANSI C platforms not POSIX.
> We prefer to avoid #ifdefs in the main code.

By "in the main code" I guess you mean "in .c files, rather than in .h
files"?  Because the file that I patched, liolib.c, is full of #if's, for
example on LUA_USE_POPEN, which is defined in luaconf.h, based on
LUA_USE_POSIX, which is defined in luaconf.h based on LUA_USE_LINUX, which
is what I #if'd on.  But one could certainly define another macro,
LUA_USE_WAIT, in luaconf.h based on LUA_USE_LINUX, and then #if in the .c
file based on that rather than LUA_USE_LINUX as I did.

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: file:close() return-value for pipes

Axel Kittenberger
I doubt that pclose() is in the ANSI C standard.

Does not grep here
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
nor in C89

So unless I'm mistaken if Lua is strict ANSI only it should not be
there. (Or accept Posix 2001 where pclose is from)

On Wed, Jan 19, 2011 at 2:32 PM, David Favro <[hidden email]> wrote:

> On 01/19/2011 06:22 AM, Luiz Henrique de Figueiredo wrote:
>>> This is really two changes, one which fixes the just-plain-wrong behavior of
>>> the return-value of file:close() when called on a pipe on Linux (and
>>> presumably also other posix platforms)
>>
>> Thanks for your patch but Lua targets ANSI C platforms not POSIX.
>> We prefer to avoid #ifdefs in the main code.
>
> By "in the main code" I guess you mean "in .c files, rather than in .h
> files"?  Because the file that I patched, liolib.c, is full of #if's, for
> example on LUA_USE_POPEN, which is defined in luaconf.h, based on
> LUA_USE_POSIX, which is defined in luaconf.h based on LUA_USE_LINUX, which
> is what I #if'd on.  But one could certainly define another macro,
> LUA_USE_WAIT, in luaconf.h based on LUA_USE_LINUX, and then #if in the .c
> file based on that rather than LUA_USE_LINUX as I did.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: file:close() return-value for pipes

Luiz Henrique de Figueiredo
> I doubt that pclose() is in the ANSI C standard.

You're right. Support for popen is a concession to POSIX. Sorry for the noise.

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: file:close() return-value for pipes

Roberto Ierusalimschy
In reply to this post by David Favro
> This is really two changes, one which fixes the just-plain-wrong behavior of
> the return-value of file:close() when called on a pipe on Linux (and
> presumably also other posix platforms) [this is the more important of the
> two], and the addition of a second return-value to the API, indicating the
> type of exit of the child process.  I wrapped the two into the same patch as
> I consider them to be tightly related.

Is this second returned value any useful? Even if the child process
running the command terminates with a signal, the shell running it will
terminate normally, and that will be the status returned by pclose.
It seems that almost always the type of exit will a "normal" exit.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: file:close() return-value for pipes

Sam Roberts
On Thu, Feb 10, 2011 at 9:36 AM, Roberto Ierusalimschy
<[hidden email]> wrote:
> Is this second returned value any useful? Even if the child process
> running the command terminates with a signal, the shell running it will
> terminate normally, and that will be the status returned by pclose.
> It seems that almost always the type of exit will a "normal" exit.

Are you talking about this value?

       The  pclose() function waits for the associated process to
terminate and returns the exit
       status of the command as returned by wait4(2).
        - man popen(3)

dash is /bin/sh on ubuntu, and it says this in the man page:

EXIT STATUS
     Errors that are detected by the shell, such as a syntax error,
will cause the shell to exit
     with a non-zero exit status.  If the shell is not an interactive
shell, the execution of
     the shell file will be aborted.  Otherwise the shell will return
the exit status of the
     last command executed, or if the exit builtin is used with a
numeric argument, it will
     return the argument.

And that seems to be the case:

% /bin/sh -c "/bin/true"; echo $?
0
% /bin/sh -c "/bin/false"; echo $?
1
% /bin/sh -c "exit 3"; echo $?
3

Also, the 127 return value (command not found), is invaluable for
trouble-shooting.

Cheers,
Sam

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: file:close() return-value for pipes

Roberto Ierusalimschy
> Are you talking about this value?
>
>        The  pclose() function waits for the associated process to
> terminate and returns the exit
>        status of the command as returned by wait4(2).
>         - man popen(3)
>
> [...]

I am talking about signals, as reported by the macro WIFSIGNALED. Even
when the process ran by the shell is interrupted by a signal, the shell
itself is not. For instance, if I run the following:

  f = assert(io.popen("lua -i"))
  print(f:read"*all")
  print(f:close())

and then kill the process "lua -i", f:close() (as corrected by the
proposed patch) still reports a normal termination through its
second return.

-- Roberto

12