Introducing LuaZDF - Lua Zero Dependency Functions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Introducing LuaZDF - Lua Zero Dependency Functions

Alexander Schulz
Hi,

I did developed/collected some util functions for Lua.
You can check out the functions at https://luazdf.aiq.dk/ or on https://github.com/aiq/luazdf.

Cheers,
Alexander

HTML version: https://blog.aiq.dk/introducing-luazdf.html

Introducing LuaZDF
==================

[abstract]
LuaZDF - Lua Zero Dependency Functions

== Problem

For the development of my little Lua library basexx<<1>> I needed a simple
utility function that splits a string into an array table with substrings that
have the same length.
This function is not part of the Lua standard libraries<<2>>, a quick search in
the LuaRocks<<3>> repository was also unsuccessful.
Other languages offer this kind of function in their standard library<<4>>.
In my case, I ended up implementing the function by myself.
This specific function is not rocket science by itself, but it is always easy to
create bugs when implementing software, so I would prefer an implemented and
tested function for this case.

Now it is easy to imagine that I need this function for other projects, so the
question is how to share this and other similar functions.
Therefore I introduce LuaZDF and will now explain the main design decision that
I made in developing it.

== Common Approaches

There are three common approaches I know to collect and distribute simple
utility functions.
I will describe them with a few words.

=== Big Module

One approach is to collect this kind of utility functions in a single module and
to include this module in the project.
The module would collect all kind of functions: io, string, color, etc - like
Penlight<<5>> for example.
For me, the size of this imaginary module is the biggest disadvantage of this
approach, as I would need this module for just one function, but would demand
that the rest does not bother me.
Everyone who worked with big environments and libraries knows the hassle that
follows by including big modules into a project.
You will start to depend on the decision made by the library, like deep class
structures and conventions.

=== Domain Module

You can reduce the size of one big module by creating single modules for each
domain (io, string, color, etc), but they will still include a bunch of
functions that are not required.
My little Lua library basexx itself is this kind of module.
A quick look at the projects<<6>> that are using basexx shows that just one or
two functions from the module are actually used.
The basexx module currently contains 14 functions, which means that around 90%
of the functions are not required for those projects, thus adding unnecessary
amounts of data to the project.
Also I would have to add another module dependency for my imaginary string
library that contains my util function.
This leads to even more unused code and thus more unnecessary resources.

=== Single Function Module

Considering the downsides that large amounts of unnecessary code have on your
project, the approach to create a single module for each function seems
reasonable.
The npm package manager<<7>> contains a lot modules that match this approach.
The dependency tree that this approach generates can of course lead to new
problems<<8>>.
In generall, I am in favour of this approach, as you can specifically include
those dependencies that you really need.
The main downside of this is that you end up with a lot of dependencies that
need to be managed, one for each function.

== Zero Dependency Functions (ZDF)

For LuaZDF, the available functions will be implemented separately in single
files for each function.
LuaZDF is not library like the common approaches, it is more a function
registry.
This approach seems similar to the "Single Function Module" approach but has one
major difference: you do not have to handle dependencies, as every function/file
contains all necessary source code for it to function on its own.
LuaZDF follows the principle that is best described with the following Go
Proverb<<9>>:
....
A little copying is better than a little dependency.
....
This means that all functions work out of the box when you copy them into your
project.
I need to tell you one restriction in the second sentence, that is to say that
not all dependencies
are expendable.
For example, it is hard in Lua to work on the file system without using
LuaFileSystem<<10>>.
But all functions inside the ZDF registry are independent and have zero
dependencies among themselves.

Let me show you with an example what that means.
The usefull function<<11>> _dayofweek_ requires the function _isleapyear_ to
work.
The DRY principle<<12>> would automatically lead to two seperate functions.
That is not wrong, but it leads to abstraction that hides functionality and adds
dependency.

With the ZDF approach I try to offer/collect all kind of useful functions that
are easy to add into a project and have a small footprint regarding their
dependencies and size.

== Coding vs. Managing

You may still question yourself: "Why do you not just add single function
modules to LuaRocks?"
That was the first question from a friend, when I told him about the ZDF
approach.
For me the main problem with every package manager is the task of managing all
the dependencies.
I love to code, but everything that has to do with managing is a horror for me.

I talk about both sides here, the creation and use of packages.
The convention over configuration<<13>> paradigm reduces a lot of work, but I
have problems with creating the packages.
LuaRocks for example already has a
simple and easy way to create a package<<14>>, but that does not help me much.
I always struggle with things that feel like configuration.
For me, creating and updating the rockspec file<<15>> is the part with the
lowest level of joy.

The main problems on using packages often are the dependencies and their
management.
For example almost all package managers force you to define a required version
for a package.
My experience is that in most cases the packages are just defining the minimum
version and ignore a maximum version where the code compiles or runs correctly.
I unterstand the motivation but it breaks my code so often - it really hurts.

On the other side, I like approaches like stb<<16>> where you can just copy the
code into your project, and have nothing to manage afterwards.
Also, the code is viewable up front and is not hidden within a package
structure.
I don't know how to discribe it better as that "you actually see the code".
You also have the responsibility to include new versions of the used code to
your project, as there is no automatic management of getting newer versions - I
hope that the simple kind of the functions within LuaZDF do not require many
updates.

== Closing Words

I tried to give you a rough understanding about the ideas and decisions behind
LuaZDF.
If things are still unclear, check out the website<<17>> for more information or
write a question on reddit<<18>>.

== Sources
[bibliography]
- [[[1]]] https://github.com/aiq/basexx
- [[[2]]] https://www.lua.org/manual/5.3/manual.html#6
- [[[3]]] https://luarocks.org/
- [[[4]]] http://php.net/manual/en/function.str-split.php
- [[[5]]] http://stevedonovan.github.io/Penlight/api/index.html
- [[[6]]] https://luarocks.org/modules/aiq/basexx
- [[[7]]] https://www.npmjs.com/
- [[[8]]] http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/
- [[[9]]] https://go-proverbs.github.io/
- [[[10]]] https://keplerproject.github.io/luafilesystem/
- [[[11]]] http://onemanmmo.com/index.php?cmd=newsitem&comment=news.1.392.0 
- [[[12]]] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
- [[[13]]] https://github.com/luarocks/luarocks/wiki/Creating-a-rock
- [[[14]]] https://github.com/aiq/basexx/blob/master/dist/basexx-0.4.0-1.rockspec
- [[[15]]] https://en.wikipedia.org/wiki/Convention_over_configuration
- [[[16]]] https://github.com/nothings/stb
- [[[17]]] https://luazdf.aiq.dk/
- [[[18]]] https://www.reddit.com/r/LuaZDF/
Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Sean Conner
It was thus said that the Great Alexander Schulz once stated:
>
> The main problems on using packages often are the dependencies and their
> management. For example almost all package managers force you to define a
> required version for a package. My experience is that in most cases the
> packages are just defining the minimum version and ignore a maximum
> version where the code compiles or runs correctly. I unterstand the
> motivation but it breaks my code so often - it really hurts.

  I'm not sure what you are saying here.  At the one extream, you can
specify:

        dependencies =
        {
          "lua" -- any version of Lua, even 1.0!
        }

and at the other end:

        dependencies =
        {
          "lua >= 5.1, < 5.4"
        }

If you stuff really is zero dependency functions, then what's the problem
with specifying "lua >= 5.1, < 5.4" (where Lua 5.4 doesn't exist yet)?

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Daurnimator
In reply to this post by Alexander Schulz
On 13 February 2018 at 13:10, Alexander Schulz <[hidden email]> wrote:
> For the development of my little Lua library basexx<<1>> I needed a simple
> utility function that splits a string into an array table with substrings that
> have the same length.

Please don't do this! Don't split into a table to just iterate over
the table: use iterators and do it as a stream.

basexx leaves much performance on the table due to some decisions like
this, I've been meaning to send a PR, but haven't had time :(

Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Alexander Schulz
The functions from basexx are also part of luazdf.

You can check this version like http://luazdf.aiq.dk/fn/tobase32.html .
It still uses a extra table.
You can send an PR or discuss it on https://www.reddit.com/r/LuaZDF/.

I hope the structure of luazdf motivates more to to create a PR.

Thanks.

> Am 13.02.2018 um 22:56 schrieb Daurnimator <[hidden email]>:
>
> On 13 February 2018 at 13:10, Alexander Schulz <[hidden email]> wrote:
>> For the development of my little Lua library basexx<<1>> I needed a simple
>> utility function that splits a string into an array table with substrings that
>> have the same length.
>
> Please don't do this! Don't split into a table to just iterate over
> the table: use iterators and do it as a stream.
>
> basexx leaves much performance on the table due to some decisions like
> this, I've been meaning to send a PR, but haven't had time :(
>


Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Alexander Schulz
In reply to this post by Sean Conner

> Am 13.02.2018 um 22:45 schrieb Sean Conner <[hidden email]>:
>
> It was thus said that the Great Alexander Schulz once stated:
>>
>> The main problems on using packages often are the dependencies and their
>> management. For example almost all package managers force you to define a
>> required version for a package. My experience is that in most cases the
>> packages are just defining the minimum version and ignore a maximum
>> version where the code compiles or runs correctly. I unterstand the
>> motivation but it breaks my code so often - it really hurts.
>
>  I'm not sure what you are saying here.  At the one extream, you can
> specify:
>
> dependencies =
> {
>  "lua" -- any version of Lua, even 1.0!
> }
>
> and at the other end:
>
> dependencies =
> {
>  "lua >= 5.1, < 5.4"
> }

I know that this is possible, but my experience is that in most cases the packages
do just definine the minimum version with the hope that the interface does not break.
It’s not just Luarocks packages.

>
> If you stuff really is zero dependency functions, then what's the problem
> with specifying "lua >= 5.1, < 5.4" (where Lua 5.4 doesn't exist yet)?
>
>  -spc

I know, I've thought a lot about that how to include different versions of the functions
for specific Lua Version. I haven’t found a good answer.
I am open for ideas.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Miha Cooper
This project looks pretty interesting for me. Here is a lot of helpful functions and no dependencies, yey!

After the first look at the project I have a question or suggestion. Do you suppose that users will copy necessary files to their projects manually?
If so, I think it's strange. Why not to add "init.lua" to the root directory of the ZDF and the same "init.lua" to each subdirectory?
So, we would be able to do this:

zdf = require "luazdf"
zdf.str.lines()

or if we don't need the whole library:

zdf_str = require "luazdf.str"
zdf_str.lines()

This will make you library more comfortable, IMHO.


On 14 February 2018 at 10:19, Alexander Schulz <[hidden email]> wrote:

> Am 13.02.2018 um 22:45 schrieb Sean Conner <[hidden email]>:
>
> It was thus said that the Great Alexander Schulz once stated:
>>
>> The main problems on using packages often are the dependencies and their
>> management. For example almost all package managers force you to define a
>> required version for a package. My experience is that in most cases the
>> packages are just defining the minimum version and ignore a maximum
>> version where the code compiles or runs correctly. I unterstand the
>> motivation but it breaks my code so often - it really hurts.
>
>  I'm not sure what you are saying here.  At the one extream, you can
> specify:
>
>       dependencies =
>       {
>         "lua" -- any version of Lua, even 1.0!
>       }
>
> and at the other end:
>
>       dependencies =
>       {
>         "lua >= 5.1, < 5.4"
>       }

I know that this is possible, but my experience is that in most cases the packages
do just definine the minimum version with the hope that the interface does not break.
It’s not just Luarocks packages.

>
> If you stuff really is zero dependency functions, then what's the problem
> with specifying "lua >= 5.1, < 5.4" (where Lua 5.4 doesn't exist yet)?
>
>  -spc

I know, I've thought a lot about that how to include different versions of the functions
for specific Lua Version. I haven’t found a good answer.
I am open for ideas.

Thanks.



--
With best regards,
Kupriyanov Mikhail.
Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Pierre Chapuis
In reply to this post by Alexander Schulz
On Tue, Feb 13, 2018, at 22:10, Alexander Schulz wrote:

> LuaZDF follows the principle that is best described with the following Go
> Proverb: A little copying is better than a little dependency.

This is a very good counterpoint to what was proposed in another thread yesterday, and I agree with this approach to sharing utility functions.

If I may offer a suggestion: search doesn't work really well because it only filters the name of the functions. For instance, if you search for "divisor", you won't find "gcd".

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

steve donovan
On Wed, Feb 14, 2018 at 11:11 AM, Pierre Chapuis <[hidden email]> wrote:
> If I may offer a suggestion: search doesn't work really well because it only filters the name of the functions. For instance, if you search for "divisor", you won't find "gcd".

Yes, particularly if it's one of those big does-everything packages
like Penlight :)   So there's also an argument for _little,
searchable_ rocks.

Hisham and I were talking about the splitting-strings-into-tables and
noticed that nearly every large Lua program re-implements this. But
yes, as Dauminator says, prefer iterators - much less allocation.

Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Pierre Chapuis
On Wed, Feb 14, 2018, at 11:04, steve donovan wrote:
> On Wed, Feb 14, 2018 at 11:11 AM, Pierre Chapuis <[hidden email]> wrote:
> > If I may offer a suggestion: search doesn't work really well because it only filters the name of the functions. For instance, if you search for "divisor", you won't find "gcd".
>
> Yes, particularly if it's one of those big does-everything packages
> like Penlight :)   So there's also an argument for _little,
> searchable_ rocks.

Not sure I was very clear, I was talking about the search bar on http://luazdf.aiq.dk.

Basically I thin full text search in the descriptions instead of just the function names would be better.

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Dirk Laurie-2
In reply to this post by steve donovan
2018-02-14 12:04 GMT+02:00 steve donovan <[hidden email]>:

> Hisham and I were talking about the splitting-strings-into-tables and
> noticed that nearly every large Lua program re-implements this.

That merely goes to show that the problem does not have
a one-size-fits-all solution. Even small programs re-implement this.
E.g. I use a collector object, and usually don't even bother to find
an existing program that has one. I just type it in every time.

   do
local collect = {__index =
   function(tbl,x) rawset(tbl,#tbl+1,x) end
}
function collector()
  return setmetatable({},collect)
end
   end

words = collector()
("the quick brown fox jumps over the lazy dog"):gsub("%S+",words)


Sometimes the collector has added functionality, e.g. FIFO or
LIFO retrieval.

I don't expect everyone to like this way of doing it, but there's no way
I'm going to peruse docs just to find out if there is something
super-duper on the shelf.

Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Sean Conner
In reply to this post by Alexander Schulz
It was thus said that the Great Alexander Schulz once stated:
>
> > Am 13.02.2018 um 22:45 schrieb Sean Conner <[hidden email]>:
> >
> > If you stuff really is zero dependency functions, then what's the problem
> > with specifying "lua >= 5.1, < 5.4" (where Lua 5.4 doesn't exist yet)?
>
> I know, I've thought a lot about that how to include different versions of the functions
> for specific Lua Version. I haven’t found a good answer.
> I am open for ideas.

  I did a few spot checks, and from what I saw, there wasn't anything in the
funtions I looked at that was specific to a particular Lua version.  But if
it came down to it:

        if _VERSION == "Lua 5.1" then
          return function() -- Lua 5.1 version
          end

        elseif _VERSION == "Lua 5.2" then
          return function() -- Lua 5.2 version
          end

        elseif _VERSION == "Lua 5.3" then
          return function() -- Lua 5.3 version
          end

        else
          error("Unsupported version of Lua")
        end

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Coda Highland
On Wed, Feb 14, 2018 at 2:46 PM, Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Alexander Schulz once stated:
>>
>> > Am 13.02.2018 um 22:45 schrieb Sean Conner <[hidden email]>:
>> >
>> > If you stuff really is zero dependency functions, then what's the problem
>> > with specifying "lua >= 5.1, < 5.4" (where Lua 5.4 doesn't exist yet)?
>>
>> I know, I've thought a lot about that how to include different versions of the functions
>> for specific Lua Version. I haven’t found a good answer.
>> I am open for ideas.
>
>   I did a few spot checks, and from what I saw, there wasn't anything in the
> funtions I looked at that was specific to a particular Lua version.  But if
> it came down to it:
>
>         if _VERSION == "Lua 5.1" then
>           return function() -- Lua 5.1 version
>           end
>
>         elseif _VERSION == "Lua 5.2" then
>           return function() -- Lua 5.2 version
>           end
>
>         elseif _VERSION == "Lua 5.3" then
>           return function() -- Lua 5.3 version
>           end
>
>         else
>           error("Unsupported version of Lua")
>         end
>
>   -spc

That will work as long as there's no new syntax in newer versions that
make the older parser choke.

You could work around that by using loadstring([[ lua code here ]]) so
that it doesn't get parsed until runtime.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Alexander Schulz
In reply to this post by Miha Cooper


> Am 14.02.2018 um 09:29 schrieb Miha Cooper <[hidden email]>:
>
> This project looks pretty interesting for me. Here is a lot of helpful functions and no dependencies, yey!
>
> After the first look at the project I have a question or suggestion. Do you suppose that users will copy necessary files to their projects manually?

No. You can use lzt<1> with the subcommand inject to add the functions into a script or the makelib subcommand to create a custom Lua module.
lzt itself uses functions from LuaZDF.

[1] https://github.com/aiq/

> If so, I think it's strange. Why not to add "init.lua" to the root directory of the ZDF and the same "init.lua" to each subdirectory?

Each name is unique in the LuaZDF directory. It's not necessary to create submodules if you want prevent name collision.
And lzt allows you to create your own submodules.

> So, we would be able to do this:
>
> zdf = require "luazdf"
> zdf.str.lines()
>
> or if we don't need the whole library:
>
> zdf_str = require "luazdf.str"
> zdf_str.lines()
>
> This will make you library more comfortable, IMHO.
>
>
> On 14 February 2018 at 10:19, Alexander Schulz <[hidden email]> wrote:
>
> > Am 13.02.2018 um 22:45 schrieb Sean Conner <[hidden email]>:
> >
> > It was thus said that the Great Alexander Schulz once stated:
> >>
> >> The main problems on using packages often are the dependencies and their
> >> management. For example almost all package managers force you to define a
> >> required version for a package. My experience is that in most cases the
> >> packages are just defining the minimum version and ignore a maximum
> >> version where the code compiles or runs correctly. I unterstand the
> >> motivation but it breaks my code so often - it really hurts.
> >
> >  I'm not sure what you are saying here.  At the one extream, you can
> > specify:
> >
> >       dependencies =
> >       {
> >         "lua" -- any version of Lua, even 1.0!
> >       }
> >
> > and at the other end:
> >
> >       dependencies =
> >       {
> >         "lua >= 5.1, < 5.4"
> >       }
>
> I know that this is possible, but my experience is that in most cases the packages
> do just definine the minimum version with the hope that the interface does not break.
> It’s not just Luarocks packages.
>
> >
> > If you stuff really is zero dependency functions, then what's the problem
> > with specifying "lua >= 5.1, < 5.4" (where Lua 5.4 doesn't exist yet)?
> >
> >  -spc
>
> I know, I've thought a lot about that how to include different versions of the functions
> for specific Lua Version. I haven’t found a good answer.
> I am open for ideas.
>
> Thanks.
>
>
>
> --
> With best regards,
> Kupriyanov Mikhail.


Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Alexander Schulz
In reply to this post by Pierre Chapuis
Good Point.

The website is a static site that can be generated with https://github.com/aiq/luazdf-website.
I think at the weekend about a solution.

> Am 14.02.2018 um 10:11 schrieb Pierre Chapuis <[hidden email]>:
>
> On Tue, Feb 13, 2018, at 22:10, Alexander Schulz wrote:
>
>> LuaZDF follows the principle that is best described with the following Go
>> Proverb: A little copying is better than a little dependency.
>
> This is a very good counterpoint to what was proposed in another thread yesterday, and I agree with this approach to sharing utility functions.
>
> If I may offer a suggestion: search doesn't work really well because it only filters the name of the functions. For instance, if you search for "divisor", you won't find "gcd".
>
> --
> Pierre Chapuis
>


Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Miha Cooper
Why do you not consider to give people opportunities to use ZDF as regular libarary AS WELL, not only using lzt.
I mean much more useful and familiar way is:
  1. clone ZDF repo using git (or add as git submodule) or install using luarocks
  2. Write "require 'luazdf.math'" in you project (for that you should extend your lib)
I think it's better to give users BOTH ways and they will decide which one is better: copying without dependencies or add dependency without copying.

I like this project by the way and may contribute in case you agree with my suggestions =)


On 15 February 2018 at 02:22, Alexander Schulz <[hidden email]> wrote:
Good Point.

The website is a static site that can be generated with https://github.com/aiq/luazdf-website.
I think at the weekend about a solution.

> Am 14.02.2018 um 10:11 schrieb Pierre Chapuis <[hidden email]>:
>
> On Tue, Feb 13, 2018, at 22:10, Alexander Schulz wrote:
>
>> LuaZDF follows the principle that is best described with the following Go
>> Proverb: A little copying is better than a little dependency.
>
> This is a very good counterpoint to what was proposed in another thread yesterday, and I agree with this approach to sharing utility functions.
>
> If I may offer a suggestion: search doesn't work really well because it only filters the name of the functions. For instance, if you search for "divisor", you won't find "gcd".
>
> --
> Pierre Chapuis
>





--
With best regards,
Kupriyanov Mikhail.
Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

Alexander Schulz
I created a topic on reddit for this discussion.

https://www.reddit.com/r/LuaZDF/comments/7xu3au/general_how_to_include_luazdf_into_luarocks/

> Am 15.02.2018 um 09:28 schrieb Miha Cooper <[hidden email]>:
>
> Why do you not consider to give people opportunities to use ZDF as regular libarary AS WELL, not only using lzt.
> I mean much more useful and familiar way is:
> • clone ZDF repo using git (or add as git submodule) or install using luarocks
> • Write "require 'luazdf.math'" in you project (for that you should extend your lib)
> I think it's better to give users BOTH ways and they will decide which one is better: copying without dependencies or add dependency without copying.
>
> I like this project by the way and may contribute in case you agree with my suggestions =)
>
>
> On 15 February 2018 at 02:22, Alexander Schulz <[hidden email]> wrote:
> Good Point.
>
> The website is a static site that can be generated with https://github.com/aiq/luazdf-website.
> I think at the weekend about a solution.
>
> > Am 14.02.2018 um 10:11 schrieb Pierre Chapuis <[hidden email]>:
> >
> > On Tue, Feb 13, 2018, at 22:10, Alexander Schulz wrote:
> >
> >> LuaZDF follows the principle that is best described with the following Go
> >> Proverb: A little copying is better than a little dependency.
> >
> > This is a very good counterpoint to what was proposed in another thread yesterday, and I agree with this approach to sharing utility functions.
> >
> > If I may offer a suggestion: search doesn't work really well because it only filters the name of the functions. For instance, if you search for "divisor", you won't find "gcd".
> >
> > --
> > Pierre Chapuis
> >
>
>
>
>
>
> --
> With best regards,
> Kupriyanov Mikhail.


Reply | Threaded
Open this post in threaded view
|

Re: Introducing LuaZDF - Lua Zero Dependency Functions

dyngeccetor8
In reply to this post by Dirk Laurie-2
On 02/14/2018 04:13 PM, Dirk Laurie wrote:
> That merely goes to show that the problem does not have
> a one-size-fits-all solution. Even small programs re-implement this.
> E.g. I use a collector object, and usually don't even bother to find
> an existing program that has one. I just type it in every time.
> [...]
> I don't expect everyone to like this way of doing it, but there's no way
> I'm going to peruse docs just to find out if there is something
> super-duper on the shelf.

In my opinion it's property of programmer: he can and do create tools
by himself.

-- Martin