Virgin tables

classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Steve Litt
On Sunday 02 January 2011 01:42:49 Alexander Gladysh wrote:
> On Sun, Jan 2, 2011 at 09:17, Alexander Gladysh <[hidden email]> wrote:
> > On Sun, Jan 2, 2011 at 08:46, steve donovan <[hidden email]>
wrote:
> >> On Sat, Jan 1, 2011 at 8:03 PM, kevin beckford <[hidden email]>
wrote:

> >>> You do not need standard libraries like Python, you need  a "Lua
> >>> Cookbook" like Perl's  "Perl Cookbook",
> >>
> >> A cookbook would be a fantastic thing, especially if we got a little
> >> gang together to write it and spread the workload.  In the meantime,
> >> the wiki continues to be a good place to keep little articles, and I
> >> hope to revive the snippets/recipes site soon.
> >
> > I, maybe, can help with some recipes, especially on Sandboxing, DSL
> > and codegeneration.
>
> Although these topics are, maybe, a bit too big for a cookbook format.
>
> Anyway, one can start with a list of topics (maybe along with a way
> for authors to commit for one or more and for potential readers to
> express their interest). We can setup a project on GH and use its wiki
> for this.
>
> I like writing, and I'm due for some Lua articles for a long time, so
> I'm willing to help. If I'll see a list of topics, I'll do a few where
> I'll know what to write.
>
> Anyone else want to step up? :-)

I will. I can code up a text-based filepicker and picklist tools for Lua.
Given my schedule it will take 6 to 10 weeks, and probably you'll all have
better ideas on how to code it so mine will be just a starting point, but I
can do it.

As far as a wishlist for standard tools for Lua, I'd like to see the
following:

* GUI interface with forms, fields, dropdowns, menus and picklists
* Interface to Postgres. It can have MySQL too, but it shouldn't be one of
those MySQL-only interfaces.
* Product to bind together the GUI and Postgres interfaces
* Web app interface

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

steve donovan
On Sun, Jan 2, 2011 at 11:02 AM, Steve Litt <[hidden email]> wrote:
> * GUI interface with forms, fields, dropdowns, menus and picklists

Have a look at http://lua-users.org/wiki/LibrariesAndBindings, there's
plenty of GUI bindings!

> * Interface to Postgres. It can have MySQL too, but it shouldn't be one of
> those MySQL-only interfaces.

LuaSQL does precisely this, and more...

> * Web app interface

You mean CGI style, web frameworks, etc? The Kepler project is the
place to go for that.

No shortage of bindings and libraries, but not always so easy to find
out what to use...

steve d.

Reply | Threaded
Open this post in threaded view
|

Lua Cookbook (was: Standard libraries (was Re: Virgin tables))

Pierre Chapuis
In reply to this post by Alexander Gladysh
 On Sun, 2 Jan 2011 09:42:49 +0300, Alexander Gladysh
 <[hidden email]> wrote:

>> I, maybe, can help with some recipes, especially on Sandboxing, DSL
>> and codegeneration.
>
> Although these topics are, maybe, a bit too big for a cookbook
> format.

 I agree, a cookbook should not contain too advanced techniques.
 Otherwise
 it will become a second "Lua Programming Gems", which would not be a
 bad
 thing, but not a cookbook either.

> Anyway, one can start with a list of topics (maybe along with a way
> for authors to commit for one or more and for potential readers to
> express their interest). We can setup a project on GH and use its
> wiki
> for this.
>
> I like writing, and I'm due for some Lua articles for a long time, so
> I'm willing to help. If I'll see a list of topics, I'll do a few
> where
> I'll know what to write.

 I can't guarantee anything but maybe I would do the same. I like the
 cookbook approach better than the Standard Libraries one, although I'm
 often grateful to stdlib / penlight when I do quick prototyping.

--
 Pierre 'catwell' Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Lua Cookbook

Marc Balmer
Am 02.01.11 13:13, schrieb Pierre Chapuis:

> On Sun, 2 Jan 2011 09:42:49 +0300, Alexander Gladysh
> <[hidden email]> wrote:
>
>>> I, maybe, can help with some recipes, especially on Sandboxing, DSL
>>> and codegeneration.
>>
>> Although these topics are, maybe, a bit too big for a cookbook format.
>
> I agree, a cookbook should not contain too advanced techniques. Otherwise
> it will become a second "Lua Programming Gems", which would not be a bad
> thing, but not a cookbook either.

Why not advanced techniques?  There is enough material for beginners
around, and we pros need something to read, too ;)

>
>> Anyway, one can start with a list of topics (maybe along with a way
>> for authors to commit for one or more and for potential readers to
>> express their interest). We can setup a project on GH and use its wiki
>> for this.
>>
>> I like writing, and I'm due for some Lua articles for a long time, so
>> I'm willing to help. If I'll see a list of topics, I'll do a few where
>> I'll know what to write.
>
> I can't guarantee anything but maybe I would do the same. I like the
> cookbook approach better than the Standard Libraries one, although I'm
> often grateful to stdlib / penlight when I do quick prototyping.

I could contribute a section on interfacing C code.


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

kevin beckford
In reply to this post by Alexander Gladysh
>> I, maybe, can help with some recipes, especially on Sandboxing, DSL
>> and codegeneration.
>
> Although these topics are, maybe, a bit too big for a cookbook format.

I disagree, this is exactly what you'd want in a cookbook, since to
address any of those topics you
would inform the reader about thinking patterns for Lua code.  The
fact that you even mentioned it in this context is illuminating.

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Henk Boom-2
On 2 January 2011 17:27, kevin beckford <[hidden email]> wrote:
>>> I, maybe, can help with some recipes, especially on Sandboxing, DSL
>>> and codegeneration.
>>
>> Although these topics are, maybe, a bit too big for a cookbook format.
>
> I disagree, this is exactly what you'd want in a cookbook, since to
> address any of those topics you
> would inform the reader about thinking patterns for Lua code.  The
> fact that you even mentioned it in this context is illuminating.

+1. Simple examples of complex topics are often extremely useful as
the first step to learning new concepts.

    henk

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

kevin beckford
In reply to this post by steve donovan
> Have a look at http://lua-users.org/wiki/LibrariesAndBindings

Hmm.

I think I get it now.  Lua really is an 'embedded' language.

I find it hard to believe that people are rolling their own ad hoc
functionality on the fly, but that is the way it is.  I had wondered
how the node.js kids were going to address things like POSIX etc:

http://www.commonjs.org/

is how.  It's a good idea to have standard libs of some kind, just in
case one inherits a project.  I remember, usually in the wee hours of
the morning  a scream, how it was like years ago with PHP.  Lots of
great code, all different etc.  Every deployment was an adventure!

I was younger then.

...

Well, I guess it's time to start porting!

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Daurnimator
In reply to this post by Mark Hamburg
So... in lack of this magical site for working on common code, I
submit for consideration a suitable array implementation:

local list_mt = { }

local table_pack = table.pack or function ( ... ) return { n = select
( "#" , ... ) , ... } end

function list ( ... )
        return setmetatable ( table_pack ( ... ) , list_mt )
end

local function check_list ( l )
        return assert ( getmetatable ( l ) == list_mt , "Not a list" )
end

local function insert ( l , i , v )
        check_list ( l )
        local sz = #l
        local new_sz = sz + 1
        assert ( type ( i ) == "number" and i > 0 and i <= new_sz , "Invalid index" )
       
        for k = sz , i , -1 do
                rawset ( l , k + 1 , rawget ( l , k ) )
        end
        rawset ( l , i , v )
        l.n = new_sz
        return l
end

local function append ( l , ... )
        check_list ( l )
        local args = table_pack ( ... )
        local sz = #l
        for i = 1 , args.n do
                rawset ( l , sz + i , rawget ( args , i ) )
        end
        l.n = sz + args.n
        return l
end

local function remove ( l , i )
        check_list ( l )
        local sz = #l
        assert ( type ( i ) == "number" and i > 0 and i <= sz )
        local v = rawget ( l , i )
        for k = i , sz do
                rawset ( l , k , rawget ( l , k + 1 ) )
        end
        l.n = sz - 1
        return l
end

local function concat  ( l1 , l2 )
        check_list ( l1 )
        check_list ( l2 )
        local r = list ( l1:unpack ( 1 , #l1 ) )
        r:append ( l2:unpack ( 1 , #l2 ) )
        return r
end

local function length ( l )
        check_list ( l )
        return rawget ( l , "n" )
end

list_mt.__index = {
        insert = insert ;
        append = append ;
        remove = remove ;
        length = length ;
        unpack = unpack ;
        tostring = table.concat ;
        sort = table.sort ;
}
list_mt.__len = length ;
list_mt.__ipairs = function ( l )
        local sz = #l
        return function ( l , last_i )
                local i = last_i + 1
                if i > sz then return nil end
                return i , rawget ( l , i )
        end
end ;
list_mt.__pairs = list_mt.__ipairs
list_mt.__newindex = function ( l , i , v )
        assert ( type ( i ) == "number" and i > 0 and i < #l + 1 )
        rawset ( l , i , v )
end ;
list_mt.__add = append
list_mt.__sub = remove
list_mt.__concat = concat

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Alexander Gladysh
In reply to this post by Henk Boom-2
On Mon, Jan 3, 2011 at 02:01, Henk Boom <[hidden email]> wrote:
> On 2 January 2011 17:27, kevin beckford <[hidden email]> wrote:
>>>> I, maybe, can help with some recipes, especially on Sandboxing, DSL
>>>> and codegeneration.

>>> Although these topics are, maybe, a bit too big for a cookbook format.

>> I disagree, this is exactly what you'd want in a cookbook, since to
>> address any of those topics you
>> would inform the reader about thinking patterns for Lua code.  The
>> fact that you even mentioned it in this context is illuminating.

> +1. Simple examples of complex topics are often extremely useful as
> the first step to learning new concepts.

Well, no problem. Lets put together a list of topics and a topic
format, and I'll write them. I believe that I, maybe, have something
to say on the themes I listed above. (Also other Lua-related topics,
of course, I use Lua for a long time... but the amount of time I can
put to writing is rather finite, so lets wait for a topic list.)

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Dirk Laurie
In reply to this post by Axel Kittenberger
On Sun, Jan 02, 2011 at 01:09:29AM +0200, Axel Kittenberger wrote:
> Personally I wonder if this strong focus to Python-like is a good
> idea, but this is just a far away general consideration, nothing
> I could now prove close up.

Lua is designed to be inside, not outside.  In Ubuntu Lucid there
are 2000 packages with "python" on their names, most of them
reinventions of the wheel or bindings for libraries so you can
reinvent the wheel for yourself.  They're written by Python
fundamentalists.  That's not the Lua way.  Lua says: leave the
hardware and the time-critical code to C (or whatever), but do
the user configuration and intricate logic in Lua.  The end user
does not even need to know you've linked in the Lua library.

Sure, we all write stand-alone Lua applications, I've plenty of
files starting #!/usr/bin/lua, but that's for prototyping and
non-redistributable programs.

Dirk


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Dirk Laurie
In reply to this post by Daurnimator
On Mon, Jan 03, 2011 at 02:40:06AM +0200, Quae Quack wrote:
> So... in lack of this magical site for working on common code, I
> submit for consideration a suitable array implementation:

Your code forces all indices to be numbers.  That is not necessary.
It should force all integer keys to lie in a block 1 to #a with
no holes, yes, but string keys are OK. They don't confuse the table
library functions and  are quite useful.  

E.g. this line from a data file of finite integer sequences:

entry{3,5,17,257,65537, note="all known Fermat primes", OEIS="A000215",
    formula=function (n) return 2^(2^(n-1))+1 end}

Dirk


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Cosmin Apreutesei
In reply to this post by Dirk Laurie
> Lua is designed to be inside, not outside.  In Ubuntu Lucid there
> are 2000 packages with "python" on their names, most of them
> reinventions of the wheel or bindings for libraries so you can
> reinvent the wheel for yourself.  They're written by Python
> fundamentalists.  That's not the Lua way.  Lua says: leave the
> hardware and the time-critical code to C (or whatever), but do
> the user configuration and intricate logic in Lua.  The end user
> does not even need to know you've linked in the Lua library.
>
> Sure, we all write stand-alone Lua applications, I've plenty of
> files starting #!/usr/bin/lua, but that's for prototyping and
> non-redistributable programs.

I don't think this is an actual technical reality that you're
describing. I don't think Lua's design has anything (prove me wrong)
that makes it harder to be used as standalone than embedded. I think
this rhetoric is inspired by the fact that at the present time there's
no place where you can find a major set of precompiled binaries and
documentation all in one unified place and ready to use. But that's
gonna change eventually.

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Steve Litt
In reply to this post by Dirk Laurie
On Monday 03 January 2011 05:39:57 Dirk Laurie wrote:

> Sure, we all write stand-alone Lua applications, I've plenty of
> files starting #!/usr/bin/lua, but that's for prototyping and
> non-redistributable programs.

I'm thinking maybe it's for prototyping and non-redistributable programs
because of the lack of good, sturdy, easy to use tools. I KNOW it's not
because of Lua's speed (it's fast for an interpreter). I know it's not because
of Lua's ease of use, because Lua's as easy or easier than Perl, Python and
Ruby, all of which are used for redistributable programs and production grade
programs. And last but not least, it's not because of a lack of power -- once
again from what I see the basic Lua language is more powerful than the basic
languages of Perl, Python and Ruby.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt


Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Alexander Gladysh
In reply to this post by Dirk Laurie
On Mon, Jan 3, 2011 at 13:39, Dirk Laurie <[hidden email]> wrote:
> On Sun, Jan 02, 2011 at 01:09:29AM +0200, Axel Kittenberger wrote:
>> Personally I wonder if this strong focus to Python-like is a good
>> idea, but this is just a far away general consideration, nothing
>> I could now prove close up.

> Lua is designed to be inside, not outside.  In Ubuntu Lucid there
> are 2000 packages with "python" on their names, most of them
> reinventions of the wheel or bindings for libraries so you can
> reinvent the wheel for yourself.  They're written by Python
> fundamentalists.  That's not the Lua way.  Lua says: leave the
> hardware and the time-critical code to C (or whatever), but do
> the user configuration and intricate logic in Lua.  The end user
> does not even need to know you've linked in the Lua library.

> Sure, we all write stand-alone Lua applications, I've plenty of
> files starting #!/usr/bin/lua, but that's for prototyping and
> non-redistributable programs.

My 200+ KLOC of Lua code do not agree with this assumption.

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Daurnimator
In reply to this post by Dirk Laurie
On 3 January 2011 11:01, Dirk Laurie <[hidden email]> wrote:

> On Mon, Jan 03, 2011 at 02:40:06AM +0200, Quae Quack wrote:
>> So... in lack of this magical site for working on common code, I
>> submit for consideration a suitable array implementation:
>
> Your code forces all indices to be numbers.  That is not necessary.
> It should force all integer keys to lie in a block 1 to #a with
> no holes, yes, but string keys are OK. They don't confuse the table
> library functions and  are quite useful.
>
> E.g. this line from a data file of finite integer sequences:
>
> entry{3,5,17,257,65537, note="all known Fermat primes", OEIS="A000215",
>    formula=function (n) return 2^(2^(n-1))+1 end}
>
> Dirk
>
>
>

That is not an array/list.
That is much more suited for another data format; most possibly the
native lua table.
The code I posted was for a list that accepts nil values.

PS, the code is for lua 5.2 only ==> __len needs to be respected.

Reply | Threaded
Open this post in threaded view
|

Re: Standard libraries (was Re: Virgin tables)

Dirk Laurie
On Mon, Jan 03, 2011 at 04:31:36PM +0200, Quae Quack wrote:
> The code I posted was for a list that accepts nil values.
-1




1234