The plugin dir

[serj.k...@gmail.com]

Hi Stanislav

What do you think about special plugins/ dir in the root of project? It
can contain something like:
default/
example/
another_plug/

It will contain all optional native plugins. For example once i plan to
add a function to support Lua scripts within ACTION. It can be optional
plugin.

I think it's good to invent an format of native plugin name. For example:
libclish_plugin_<name>.so or libclish_p_<name>.so
or something else.

[Stanislav Galabov]

For some reason google bounced my reply to the group so I am reposting it via web:

Man, we should have been in contact earlier :-)

I have some work on Lua ACTIONs already and I use it in our project.

Let me think about what the best way would be to push it into the smartcom branch.

About the plugin names, why don't we drop the lib prefix and go with clish_plugin_<name>.so? ( for an example of how we can make autotools work with that: http://www.flameeyes.eu/autotools-mythbuster/libtool/plugins.html )

This, in my opinion, would be both more descriptive and less misleading - it would be less likely to mistake a plugin for a shared library or try to link to it dynamically :-)
Otherwise I agree about the plugins directory with sub-dir per plugin inside. I was thinking about how we can organise this too but I like your idea.

What do you think?

Best wishes,
Stanislav

[Stanislav Galabov]

Hi Serj,

Have a quick look at the smartcom branch whenever you can, please ;-)

Best wishes,

Stanislav

--
You received this message because you are subscribed to a topic in the Google Groups "klish-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/klish-dev/LVQBJhRWc20/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to klish-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Stanislav Galabov

R&D Manager

Smartcom - Bulgaria AD

e-mail: stanisla...@smartcom.bg

[serj.k...@gmail.com]

It's great about Lua! :)
I'm novice in Lua so the help is good for me.

Let's drop lib prefix.
About current smartcon branch:

1. What is a CLISH_SCRIPTS_PATH? Do you want to load some Lua standard
libraries using this path?

2. Is it possible to implement *out? The shell script implementation of
*out was not trivial...

3. You use HOOK_INIT and HOOK_FINI. These hooks are global for klish and
I'm not sure we really need it at all :)
You shoud use CLISH_PLUGIN_INIT and CLISH_PLUGIN_FINI for these
purposses. These are plugin specific init and fini. The fini is not
implemented yet but it will be implemented soon. I plan to register FINI
function like a hooks or syms. Something like clish_plugin_add_fini(func).

4. To register action don't use hook interface. It's only a sym. Use
clish_plugin_add_sym fot it. Really there is no difference between hook
registration for CLISH_SYM_PTYPE_ACTION and sym registration. But sym
registration is a right (due to API) way.

05.04.2013 18:32, Stanislav Galabov пишет:

> Man, we should have been in contact earlier :-)
>
> I have some work on Lua ACTIONs already and I use it in our project.
>
> Let me think about what the best way would be to push it into the smartcom branch.
>
> About the plugin names, why don't we drop the lib prefix and go with clish_plugin_<name>.so? ( for an example of how we can make autotools work with that: http://www.flameeyes.eu/autotools-mythbuster/libtool/plugins.html )
>
> This, in my opinion, would be both more descriptive and less misleading - it would be less likely to mistake a plugin for a shared library or try to link to it dynamically :-)
> Otherwise I agree about the plugins directory with sub-dir per plugin inside. I was thinking about how we can organise this too but I like your idea.
>
> What do you think?
>
> Best wishes,
> Stanislav
>
>

[Stanislav Galabov]

Hi Serj,

1. Using CLISH_SCRIPTS_PATH we can load a bunch of Lua scripts (either compiled - *.bin or not compiled - *.lua). Then we can call functions/use variables from these scripts from within the ACTION tags. Actually it doesn't matter whether a *.bin script is 'compiled' or 'not compiled' - it will be loaded all the same. I've chosen these extensions as they make sense IMHO. For an example of what I'm talking about you can look at xml-examples/lua (test.xml and test.lua) and see the 'eval', 'test8' and 'test9' commands specifically.

2. It's not straightforward at all. Lua uses the same stdout as the invoking application. There are a number of ways to work around that (ranging from overriding Lua's print and io.write functions in pure Lua to including a custom Lua lib that would do the job in klish). So far I haven't had the need for **out with Lua so I haven't taken the time to think about and implement it. I can do it if/when time permits.

3. I totally agree with you on this. The only reason I am using init/fini hooks is that plugin_fini isn't here yet and because I wanted to have something working as soon as possible with git head. When we have plugin_fini I'll use that.

4. Agreed. I'll do that next week.

Best wishes,

Stanislav

[serj.k...@gmail.com]

Hi Stanislav

The plugin's fini function is implemented. See the CLISH_PLUGIN_FINI. Use it for udata.

The plugin can set its own name that can be used by builtin="sym@plugin_name". The PLUGIN tag can override this internal plugin name. See the examples/anplug.c

I don't like global environment variables that must be set by ... aaa... wrapper script may be. So i have implemented the "conf" for each plugin. Using some text between <PLUGIN> and </PLUGIN> you can set some init information for plugin. It has no special meaning. The plugin must parse it.
For example the simple conf is something like ini file with pairs var=value. You can set Lua default scripts by that mechanism. I think it will be good to implement internal simple ini parser that get multiline char* and returns something like pargv.

05.04.2013 23:15, Stanislav Galabov пишет:

--
You received this message because you are subscribed to the Google Groups "klish-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to klish-dev+...@googlegroups.com.

[Stanislav Galabov]

Hi Serj,

Done. Currently I'm just taking whatever clish_plugin__get_conf() gives me without doing any parsing, but the idea of a simple config parser (ini or otherwise) that would parse var=val pairs within <PLUGIN> </PLUGIN> tags is good IMO.

Best wishes,

Stanislav

[Stanislav Galabov]

Hi Serj,

One question about *out support in action handlers: Currently, as far as I could see (haven't looked very hard), the only user of *out is actually var. Is that correct? If so, do you see any need in short/mid/long term for anything other than var to use the output of a script?

The reason I am asking is the following:

Because Lua is actually part of the clish process, it has the same stdin/stdout/stderr as the executable itself, so it will be quite hard to get the entire stdout and pass it on to the action handler.

On the other hand, however, it's really easy (I've done it in the smartcom branch) to check if a just executed Lua ACTION has returned a string and, if so - to strdup it and give it to *out (otherwise we just make *out = NULL at the beginning of the action handler).

This way Lua scripts that return a string can be handled as if the returned string was the script's stdout and this will work for vars. The drawback is you can't really get the entire stdout output from the script, but in Lua you can also do popen (if you're executing shell commands) and capture the output this way. Moreover, having the possibility to run both Lua and shell ACTIONS - if an ACTION is in fact shell only we can use the shell handler and if it is Lua only - the Lua handler. What's left to the user to think about is what to do in case of Lua scripts that need to call into shell, but I guess that's more or less acceptable for now (moreover it's not like there are no solutions to that too).

What do you think?

Best wishes,

Stanislav

On Friday, April 5, 2013 9:49:05 PM UTC+3, Сергей Каличев wrote:

[serj.k...@gmail.com]

Hi Stanislav

What do you think about global INIT and FINI hooks? I want to remove
them because each plugin has its own constructor and destructor. What
people can use global init and fini for?

[Stanislav Galabov]

Hi Serj,

I agree that having PLUGIN_INIT and PLUGIN_FINI serves this purpose much better IMHO. I say let's remove the global INIT and FINI hooks.

Best wishes,
Stanislav

[serj.k...@gmail.com]

Ok. I'll remove them.
By the way I have moved internal builtin plugin to plugin/default dir. Unfortunately I have not use your patch due to non-obvious race conditions beetween STARTUP and HOOK processing.

08.04.2013 18:34, Stanislav Galabov О©╫О©╫О©╫О©╫О©╫:

Hi Serj,

I agree that having PLUGIN_INIT and PLUGIN_FINI serves this purpose much better IMHO. I say let's remove the global INIT and FINI hooks.

Best wishes,
Stanislav

On Monday, April 8, 2013 5:31:50 PM UTC+3, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ wrote:

Hi Stanislav

What do you think about global INIT and FINI hooks? I want to remove
them because each plugin has its own constructor and destructor. What
people can use global init and fini for?

--
You received this message because you are subscribed to the Google Groups "klish-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to klish-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

О©╫
О©╫

[serj.k...@gmail.com]

08.04.2013 16:30, Stanislav Galabov пишет:

[serj.k...@gmail.com]

Hi Stanislav

Sorry for empty answer :)
Yes, that's correct. The user of **out is VARs. I can't thought out any other client for **out.
The disadvantage is VAR's ACTION and COMMAND's ACTION are not unified.
Ok, let's use current version. if your patch is ready i will integrate it to the main branch. Please implement --with-lua and --without-lua configure options. Default is --without-lua.

08.04.2013 16:30, Stanislav Galabov пишет:

Hi Serj,

[Stanislav Galabov]

Hi Serj,

While waiting for your answer I thought of a way to get the entire stdout from Lua into klish. It is a little heavy for my taste as it uses fork and a pipe. The child process dup2's its stdout to the writing end of the pipe and closes the reading end of the pipe. The parent process closes the writing end of the pipe and reads until there is stuff to read (much like in the shell **out case). What I don't like about this approach is that we have to fork in order to execute an ACTION. However, on the other hand, it gives us unified handling in both shell and Lua cases.

What is your opinion on this?

Regarding --with-lua and --without-lua - I have an issue that I am still thinking about here. The problem is that basically most Linux distributions have differing names and locations of both Lua libs and headers. FreeBSD is no different - it has its own locations, different than anything I've seen on Linux. :-)

One way I see is that we only check for liblua.so and Lua headers and if we find them - we link to them. If we don't - then it's the user's responsibility to either provide CFLAGS and LDFLAGS on the command line or make liblua.so a link to the proper library and make links to the proper headers such that configure can find and use them.

Unfortunately I have no other idea at the moment and it seems that this issue is pretty widespread in other projects too.

What do you think?

Best wishes,

Stanislav

[serj.k...@gmail.com]

Hi

I think the fork and pipe is not good. Because the advantage of builtin Lua is a simplicity and a speed. Without Lua-plugin we can use shebang="/usr/bin/lua" in ACTION and get the same behaviour. But it's not very fast and simple.

I'm not sure but what do you think about to always get string from Lua and if it's not-null - send it to stdout. So if **out is needed it will get Lua out string but if **out is not needed it will be printed to the screen.

Do the Lua headers have no fixed place too? Is --with-lua=<path_to_lib> not enough? Does Lua have pkg-config files?



08.04.2013 19:17, Stanislav Galabov пишет:

[Stanislav Galabov]

Hi Serj,

When I say fork and pipe I don't mean "fork a new shell and then use a pipe to read" :-)

I mean the following:

        if ((childpid = fork()) == -1) {

                perror("fork");

                return -1;

        }

        if (childpid == 0) { /* Child */

                dup2(fd[1], 1);

                close(fd[0]);

                close(fd[1]);

                exit(exec_action(L, script));

        } else { /* Parent */

                close(fd[1]);

                buf = konf_buf_new(fd[0]);

                while(konf_buf_read(buf) > 0);

                *out = konf_buf__dup_line(buf);

                konf_buf_delete(buf);

                close(fd[0]);

        }

This has one main indisputable advantage over using Lua shebang: all scripts and Lua libraries are already loaded and all globals are evaluated. What's left is to evaluate the actual script itself (which could consist of a simple function call to an already defined Lua function). So the overhead of the above is immeasurably lower than having to spawn a new shell, etc.

I guess I'd be ok with the above, moreover knowing that we really only use it for vars. If you insist, however, I can get back to the implementation where Lua scripts that are needed for vars can (and should) return a string that's to be used for the var's purposes.

Regarding pkg-config - probably exists for some platforms, but I am not certain... I am thinking of a way to check for certain names in certain predefined locations - this way the likelihood of finding the lib and headers would be increased as much as possible. I need a couple more days to think this through..

Best wishes,

Stanislav

[serj.k...@gmail.com]

Hi

Ok, no objections. Let's try it.

08.04.2013 23:02, Stanislav Galabov пишет:

[serj.k...@gmail.com]

Hi Stanislav

I have implemented API for context. See the clish/shell/context.c. The context structure is opaque now.

I don't understand about current state of lua plugin. Is it ready for integration to master branch?


08.04.2013 23:02, Stanislav Galabov пишет:

[Stanislav Galabov]

Hi Serj,

With the exception of finding/detecting Lua via configure.ac, the plugin itself is ready.

I will have to rework it to support your context changes, but that should be trivial.

As I mentioned before - I'll need a little time to think about the best way to detect Lua in configure.ac. In the meantime we could do something like this (if --with-lua is given to configure):

- Look for liblua.so in the default lib search path. If that fails - fail.

- Look for the Lua headers in the default locations as well. If that fails - fail.

This way the user would have to either provide CFLAGS and LDFLAGS to configure that would include the directories that contain liblua.so and the headers or 'ln -s' to the right files within the usual lib and include dirs.

What do you think?

Best wishes,

Stanislav

 

You received this message because you are subscribed to a topic in the Google Groups "klish-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/klish-dev/LVQBJhRWc20/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to klish-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[serj.k...@gmail.com]

Good. I'll try to integrate lua plugin to the master branch. The right library searching can be implemented later.
My coworker - the Lua fan use pkg-config to search for Lua. I think it's good. We can use pkg-config and if pkg-config is not exists or can't find lua we can look for lua.so in some default paths.


09.04.2013 15:22, Stanislav Galabov пишет:

[Stanislav Galabov]

The issue with pkg-config is the same as the issue with Lua itself - on FreeBSD the .pc file is lua-5.1.pc. On a Linux box I have around (Ubuntu) - it's lua5.1.pc.

And on targets where we compile a Lua as part of a bigger project - pkg-config is not always an option either…

Anyway, I've made configure.ac look for liblua.so and Lua headers in the default places. If it fails to compile - CPPFLAGS and/or LDFLAGS need to be passed to configure.

I've merged master into smartcom and also I've converted the Lua plugin to use clish_context__get_shell() where needed (1 place). So now the Lua plugin should be ready for integration into master.

Best wishes,

Stanislav

[serj.k...@gmail.com]

Integrated. Thanks!

09.04.2013 15:57, Stanislav Galabov пишет:

[serj.k...@gmail.com]

Hi Stanislav

For the test purposes i have add m4/ax_lua.m4. It's a "standard" autotools template to check for Lua. See the AX_LUA_LIBS and AX_LUA_HEADERS in configure.ac.
It works on my Ubuntu.
What do you think about it?


08.04.2013 23:02, Stanislav Galabov пишет:

[Stanislav Galabov]

Hi Serj,

Unfortunately I have issues, especially when cross-compiling, when using AX_LUA_LIBS and AX_LUA_HEADERS.

For example, configure tries to be clever and compile a program to check for the LUA_VERSION specified. This is fine until it tries to execute the compiled program, which, when cross compiling, is a bad idea :-)

On the other hand, if I don't specify a LUA_VERSION, it doesn't want to run either as it says it needs LUA_VERSION in order to check for Lua :-) So it's a kind of catch 22 situation.

Best wishes,

Stanislav

You received this message because you are subscribed to a topic in the Google Groups "klish-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/klish-dev/LVQBJhRWc20/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to klish-dev+...@googlegroups.com.

[Stanislav Galabov]

Hi Serj,

ax_lua.m4 (specifically AX_LUA_HEADERS) is using AC_RUN_IFELSE to check whether the Lua headers found do really really really match the version of Lua specified with LUA_VERSION (I am not quite sure we really need this check).

The issue was, in the call to AC_RUN_IFELSE, AX_LUA_HEADERS did not provide "action if cross-compiling", so configure was failing.

I've added an "action if cross-compiling" that just basically says "it's ok, the versions match, go ahead" and now everything seems to be ok.

I've merged your latest changes into smartcom and made my changes on top. You can merge smartcom into master safely I guess.

Best wishes,

Stanislav

[serj.k...@gmail.com]

Merged. Thanks.

10.04.2013 12:58, Stanislav Galabov пишет:

[serj.k...@gmail.com]

Hi Stanislav.

I have change the internal plugin name from "lua_hooks" to "lua" and
exported lua sym name from "hook_action" to "lua". Do you have any
objections?

Be carefull with -export-symbols-regex. The lua plugin couldn't export
clish_plugin_init() due to regexp.

[Stanislav Galabov]

Hi Serj,

No objections on the name changes. I've also changed the references to the plugin in xml-examples/lua/*.xml

One thing I noticed is we have a default_builtin attribute for the STARTUP tag defined in the schema file, but this hasn't been implemented yet. Do you plan to implement it?

Regarding the -export-symbols-regex - I tried to use it in order to restrict what gets exported, but it seems to do nothing on FreeBSD. I guess I left it there instead of removing it completely… in the meantime I am looking at a solution that would work for both *BSD and Linux (if there is one)…

Best wishes,
Stanislav

> --
> You received this message because you are subscribed to a topic in the Google Groups "klish-dev" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/klish-dev/LVQBJhRWc20/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to klish-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[serj.k...@gmail.com]

I've forget about default_builtin. :) Thanks for the reminder. I thought
it's already implemented. I'll implement it today.

10.04.2013 15:10, Stanislav Galabov пишет:

[Stanislav Galabov]

Thanks.

In the meantime, have you had a chance to play a little with the Lua plugin? If so, does it work ok for you?

Best wishes,
Stanislav

[serj.k...@gmail.com]

I'm totaly forget everything :)
The new implementation of default_builtin is <HOOK name="action"
builtin="lua@lua"/>. It works.
The default_plugin will be removed.

The lua plugin and "Lua hello world" works for me.

10.04.2013 16:26, Stanislav Galabov пишет:

[Stanislav Galabov]

Hi Serj,

Ok, thanks. I've updated xml-examples/lua/*.xml to reflect all this :-)
Also, I think I finally have a solution for hiding plugin symbols properly - works on FreeBSD, should work on Linux too.
It consists of the following:
In configure.ac we check if LD supports --version-script parameter. If so - it sets an AM_CONDITIONAL (HAVE_LD_VERSION_SCRIPT), which is then used in module.am of each plugin that wants to only export relevant symbols. If the conditional is true - we use version scripts. If it is false - we use a symbol file, which simply lists all symbols we wish to export (one per line). The latter option doesn't work on FreeBSD for some reason, but it seems as a good fallback.

Best wishes,
Stanislav

On Apr 10, 2013, at 3:36 PM, "serj.k...@gmail.com" <serj.k...@gmail.com> wrote:

> I'm totaly forget everything :)
> The new implementation of default_builtin is <HOOK name="action" builtin="lua@lua"/>. It works.
> The default_plugin will be removed.
>
> The lua plugin and "Lua hello world" works for me.
>
> 10.04.2013 16:26, Stanislav Galabov пишет:
>> Thanks.
>>
>> In the meantime, have you had a chance to play a little with the Lua plugin? If so, does it work ok for you?
>>
>> Best wishes,
>> Stanislav
>>
>> On Apr 10, 2013, at 3:16 PM, "serj.k...@gmail.com" <serj.k...@gmail.com> wrote:
>>
>>> I've forget about default_builtin. :) Thanks for the reminder. I thought it's already implemented. I'll implement it today.
>>>
>>> 10.04.2013 15:10, Stanislav Galabov пишет:
>>>> Hi Serj,
>>>>
>>>> No objections on the name changes. I've also changed the references to the plugin in xml-examples/lua/*.xml
>>>>
>>>> One thing I noticed is we have a default_builtin attribute for the STARTUP tag defined in the schema file, but this hasn't been implemented yet. Do you plan to implement it?
>>>>

>>>> Regarding the -export-symbols-regex - I tried to use it in order to restrict what gets exported, but it seems to do nothing on FreeBSD. I guess I left it there instead of removing it completely... in the meantime I am looking at a solution that would work for both *BSD and Linux (if there is one)...

[serj.k...@gmail.com]

Hi Stanislav

Is it really important? For example default plugin has no symbols to hide.
Anyway I have used the following mechanism to hide symbols:

#ifndef SYM_HIDDEN
#define SYM_HIDDEN __attribute__((visibility("hidden")))
#endif

SYM_HIDDEN aud_info_t _fs_aud_info = NULL;

Another mechanisms were less suitable.



v Galabov пишет:

[Stanislav Galabov]

Hi Serj,

I wouldn't say it's very important, it is more "nice to have" than anything.
Moreover the overhead of checking whether ld supports --version-script in configure is not that big, so I don't see a reason not to leave it in. It will be good to know that somewhere down the road we do not have to revisit this.

I am not sure whether all versions of gcc we may run into support the visibility attribute, so we may have to implement a similar mechanism in configure to detect this, so again - additional work will be needed, however little it is... I think I prefer to use the method I have already implemented if/when needed... What do you think?

Best wishes,
Stanislav

On 10.04.2013, at 19:44, "serj.k...@gmail.com" <serj.k...@gmail.com> wrote:

> Hi Stanislav
>
> Is it really important? For example default plugin has no symbols to hide.
> Anyway I have used the following mechanism to hide symbols:
>
> #ifndef SYM_HIDDEN
> #define SYM_HIDDEN __attribute__((visibility("hidden")))
> #endif
>
> SYM_HIDDEN aud_info_t _fs_aud_info = NULL;
>
> Another mechanisms were less suitable
>
>

[serj.k...@gmail.com]

No problem. If it's suitable for you - do it.

10.04.2013 21:21, Stanislav Galabov пишет:

[Stanislav Galabov]

It's done. If you wish you can merge it into master.

Best wishes,
Stanislav

[serj.k...@gmail.com]

Applied. Thanks.

10.04.2013 21:41, Stanislav Galabov О©╫О©╫О©╫О©╫О©╫:

> It's done. If you wish you can merge it into master.
>
> Best wishes,
> Stanislav
>
> On Apr 10, 2013, at 8:38 PM, "serj.k...@gmail.com" <serj.k...@gmail.com> wrote:
>
>> No problem. If it's suitable for you - do it.
>>

>> 10.04.2013 21:21, Stanislav Galabov О©╫О©╫О©╫О©╫О©╫:

>>> Hi Serj,
>>>
>>> I wouldn't say it's very important, it is more "nice to have" than anything.
>>> Moreover the overhead of checking whether ld supports --version-script in configure is not that big, so I don't see a reason not to leave it in. It will be good to know that somewhere down the road we do not have to revisit this.
>>>
>>> I am not sure whether all versions of gcc we may run into support the visibility attribute, so we may have to implement a similar mechanism in configure to detect this, so again - additional work will be needed, however little it is... I think I prefer to use the method I have already implemented if/when needed... What do you think?
>>>
>>> Best wishes,
>>> Stanislav
>>>
>>> On 10.04.2013, at 19:44, "serj.k...@gmail.com" <serj.k...@gmail.com> wrote:
>>>
>>>> Hi Stanislav
>>>>
>>>> Is it really important? For example default plugin has no symbols to hide.
>>>> Anyway I have used the following mechanism to hide symbols:
>>>>
>>>> #ifndef SYM_HIDDEN
>>>> #define SYM_HIDDEN __attribute__((visibility("hidden")))
>>>> #endif
>>>>
>>>> SYM_HIDDEN aud_info_t _fs_aud_info = NULL;
>>>>
>>>> Another mechanisms were less suitable
>>>>
>>>>

>>>> v Galabov О©╫О©╫О©╫О©╫О©╫:

>>>>> Hi Serj,
>>>>>
>>>>> Ok, thanks. I've updated xml-examples/lua/*.xml to reflect all this :-)
>>>>> Also, I think I finally have a solution for hiding plugin symbols properly - works on FreeBSD, should work on Linux too.
>>>>> It consists of the following:
>>>>> In configure.ac we check if LD supports --version-script parameter. If so - it sets an AM_CONDITIONAL (HAVE_LD_VERSION_SCRIPT), which is then used in module.am of each plugin that wants to only export relevant symbols. If the conditional is true - we use version scripts. If it is false - we use a symbol file, which simply lists all symbols we wish to export (one per line). The latter option doesn't work on FreeBSD for some reason, but it seems as a good fallback.
>>>>>
>>>>> Best wishes,
>>>>> Stanislav
>>>>>
>>>>> On Apr 10, 2013, at 3:36 PM, "serj.k...@gmail.com" <serj.k...@gmail.com> wrote:
>>>>>
>>>>>> I'm totaly forget everything :)
>>>>>> The new implementation of default_builtin is <HOOK name="action" builtin="lua@lua"/>. It works.
>>>>>> The default_plugin will be removed.
>>>>>>
>>>>>> The lua plugin and "Lua hello world" works for me.
>>>>>>

>>>>>> 10.04.2013 16:26, Stanislav Galabov О©╫О©╫О©╫О©╫О©╫:

>>>>>>> Thanks.
>>>>>>>
>>>>>>> In the meantime, have you had a chance to play a little with the Lua plugin? If so, does it work ok for you?
>>>>>>>
>>>>>>> Best wishes,
>>>>>>> Stanislav
>>>>>>>
>>>>>>> On Apr 10, 2013, at 3:16 PM, "serj.k...@gmail.com" <serj.k...@gmail.com> wrote:
>>>>>>>
>>>>>>>> I've forget about default_builtin. :) Thanks for the reminder. I thought it's already implemented. I'll implement it today.
>>>>>>>>

>>>>>>>> 10.04.2013 15:10, Stanislav Galabov О©╫О©╫О©╫О©╫О©╫:

[serj.k...@gmail.com]

Hi Stanislav

I have implemented parsing of INI-like strings. You can use it in lua
plugin.
For details see the lub/ini
For the examples see the examples/plugin/anplug.c

[Stanislav Galabov]

Hi Serj,

Done. You can integrate the changes back to master if you wish.

Best wishes,
Stanislav

[serj.k...@gmail.com]

Applied. Thanks

11.04.2013 18:29, Stanislav Galabov пишет: