my conkyrc don't launch completely with conky 1.10

[chepioq]

With conky 1.10 my conky don't launch completely.

It's difficult to explain in my poor english, but I try.

I launch a conky, it appears but not fully, it appears fully after the first update_interval, for example after 3 seconds if update_interval = 3.0, or after 300 seconds if update_interval = 300.0

The problem is I want set update_interval = 3600.0 for my conky_meteo, but if I do that, the conky appears full after one hour,

Where is the problem ? And how solve that ?

[chepioq]

For info I have five conky, and there are four with this problem.

The only that have not is problem is the one with the conky text section empty :

conky.text = [[

]]

[marcpayne]

During the first update interval, which parts of your conky.text section are not visible in the conky window? For example, if you use ${exec} somewhere, is its output missing? If objects other than ${exec} are not showing, please list those as well.

From your description, I think this may be related to #112.

[chepioq]

Ok marcpayne, it's same problem as #112.

Only lines with ${exec} and ${execi} are not displayed during the fist update interval.

[marcpayne]

Thank you for confirming that. I also use ${exec} in my config, and I am trying to figure out a decent workaround. Please leave this report open so that I (or someone else) can follow up with you later.

[plikhari]

In my case it is not just exec or execi - for example I have one script that shows images and a lua thing - The images show up instantly but the lua will execute/show up only after the update interval has ended. This happens for all my scripts and we found this during the testing stage of conkywx Five.

I have come up with a work around in lua ;-)

Basically you use a lua_startup_hook and run a lua function and store the existing update interval and change the update interval to say 0.1 - Now when the main config.text gets triggered the update interval gets restored and the first start of conky is very very fast. ExecInfo is a local function handling all read write operations to files :)

function conky_startup()
-- by paramvir 2015 conkywx
    ExecInfo({
        wfile = tconcat({'/tmp/conkywx_tmp_',conky_config:match("([^/]+)$")}),
        wtext = conky_info.update_interval,
    })
    conky_set_update_interval(0.1)
    return ''
end

Now in conky_main function you would have

    if (tonum(conky_parse("${updates}")) % 10) == 3 then
        local conf_name = tconcat({'/tmp/conkywx_tmp_',conky_config:match("([^/]+)$")})
        local uint = ExecInfo({ rfile = conf_name })
        if uint then
            conky_set_update_interval(uint)
            os.remove(conf_name)
        end
    end

If you use conkywx - this code is in the conkywx.lua file

[marcpayne]

@plikhari Thank you for the Lua workaround! Since you seem to have some experience with Lua scripting, I have a question or two. Are you able to modify existing variables/objects that have already been set in conky.text? For example, if I have ${exec ~/mycommand.sh} in my config, can you change ~/mycommand.sh to something else, say ~/mybettercommand.sh, at runtime with Lua? If so, does that trigger a reload of the conky config? Or are you only able to create new ${exec} commands (and others)?

I apologize for my ignorance of Lua scripting. I seem to spend all my time on the C++ side that I ignore it. If you don't have answers to my questions, no problem.

The reason I ask is that I'm refactoring and streamlining the exec system, and one change in particular might cause problems that I can't anticipate. I have lots of documentation to write and more testing to do, but I should be able to push my changes to my repo this weekend.

[plikhari]

@marcpayne - no need to apologize ;-) It does not work the way you are seeing - the original exec will execute [conky side] and the lua part will use it as a trigger - on reading ~/mycommand.sh from the conky.text lua can do what ever you want. The conky.config is not reloaded.

Lua has been used in many ways to interact with conky. One of the ways is how you have stated - reading object/variables from within the conky.text. But this involves reading the output of that text - for example you have cpu1 output which can be conky_parse("${cpu1}") - this output is then used for what ever graphs etc and that is given back to conky to display.

With lua we cannot block a conky function such as exec and create another exec function afaik.

I have used a modular approach where each function in conky is called with the keyword lua function name (the function in the lua_load file). So one creates an alternative function and not use the conky version - for example ${if_match "${lua if_running mplayer}" == "1"} - this was when if_running was not working in conky.

The exec function has had a comment in the docs about high overhead - trust that will be a thing of the past :-)

Let me know if I can be of any help for your testing...

[marcpayne]

Thank you for explaining. You cleared up some misconceptions I had, and I think I'm beginning to understand now.

Regarding the overhead, I doubt there will be any improvement. There are essentially three parts to the exec system: the front end code that parses conky.text, the back end that executes the commands, and the callback system in the middle. I am working on the middle. My changes are not extensive (minor really), but they should make the code more understandable and maintainable, while fixing a few bugs and exposing nice new features that had been marked TODO.

There is one small performance improvement that shaves a few CPU instructions off each update interval. I should profile it to get some numbers. However, the time taken to execute a command and store its output won't change. The comment about high overhead will have to remain in the docs for now, unfortunately.

Once I push my changes, I will report back here and on a couple other bug reports. Any testing before I submit a PR is appreciated. :)

[marcpayne]

OK, my refactoring and documentation are "finished," although I expect I'll have to make some changes before submitting a PR. I pushed to the exec-cb-workaround branch on my own repo. See commit 3cea35f00174. If anyone is able to test, I would greatly appreciate it. I can explain how to clone my repo and compile from source, or apply a patch to your existing source, if necessary. Thanks!

[chepioq]

Ok marcpayne, I can test your commit tomorrow, and I will tell you if it works.

[plikhari]

@marcpayne Here are my findings :-)) It is working as desired - same as version 1.09. I am looking at the startup time - Basic conky kicks in immediately - though lua comes along in 3 to 6 seconds later - which was also the case in 1.09

Now - if I use my lua work around - which basically changed the update interval to 0.1 at startup till the next call to lua - which is usually the background widget and switched back to the original value - The full startup time including lua showing up - is the same as the basic conky startup time with your fix.

OK done some more investigation. Lua startup is triggered based on the update interval. I changed the value from 5 to 15 and lua started [background and other weather widgets] after 15 seconds. This is the same behaviour as conky prior to your fix.

That is why the lua work around works faster as the update interval is being tweaked.

So how do we look at that part - lua startup ?

Thank you - Looks very good :-))

[chepioq]

@marcpayne I test your commit and for me that work fine. The exec command work when I launch my conky, and not after the first update. Thank for your good job.

[marcpayne]

@chepioq and @plikhari, thank you for your testing! I'm glad the exec changes worked for you.

Regarding lua, I am going to have to investigate further, but I can't say when I will have the time -- job, life, reasons... If you know of a way to trigger a segfault (like accessing uninitialized data or running a certain function during or before the first update interval), or if you see strange messages using the -DD command-line argument, that would be very helpful.

[chepioq]

@plikhari, I don't understand what you say by "though lua comes along in 3 to 6 seconds later "

In my conky lua script come immediately.

What arguments do you use to launch lua ? I use lua_load = 'path_to_my_script_lua', and after lua_draw_hook_pre = 'main' (or other)

[plikhari]

@marcpayne I think it is fine the way it is - we do have a solution for lua - so I would consider it done.

@chepioq There are many ways to use lua with conky.

My approach is to have the user not access the lua code every time something needs to be adjusted/changed. The conky_main function in my case handles 12 widgets (animations [wind vane, anemometer, moon, clock gears] and more) - and each with a host of command line options like a regular program. This is besides the scripts like conky_startup, conky_if_running, conky_pre_exec - run once thing :-) and a few others.

lua_draw_hook_pre works if we have a single function to call - like in the case of the clock lua_draw_hook_pre = 'main -n clock -s 250 -p 15,5 -k 28 ', . Also lua_draw_hook_pre draws over the conky screen - so not usable from the get go unless you have only one thing to show. conkywx is a weather program (weather, tides, Earth Quakes etc) and shows 18+ widgets on one of the templates.

This is what I figured while writing this message - the lua clock code base is loaded prior to conky.text and shows up instantly. Something very similar is happening with lua_startup_hook - lua program file is read and compiled at the instance the startup-hook triggers. BUT on further testing if one uses a dummy startup_hook function and not touch the update interval - lua for that conky screen - shows up after the update interval while the direct text part is already drawn.

So while solving this Rubik's Cube in my mind - I think we are OK with the solution.

[chepioq]

mark can you add your commit in master's branch of conky ? the fedora maintainer need that all are in master's branch to build the rpm.

[marcpayne]

I'm not able to merge into master myself. I will make some corrections to my PR this weekend and if everything looks good, I think it will be merged.

[geo909]

Hi,

First off, thanks for taking the time to find a fix!

Do we have any estimate regarding the version of conky for which the fix will be implemented? Not in a rush here, just curious.

[chepioq]

The fix is already in the last version or conky-master, here : https://github.com/brndnmtthws/conky

[geo909]

Thanks.

Sorry, this is probably a naive question, but what is the x in the version 1.10.1-x where the fix is implemented? I did try to find it following the link you gave, but I couldn't..

The reason I'm asking is that In my arch linux system, I have installed version 1.10.1-2 from the arch repositories https://www.archlinux.org/packages/extra/i686/conky/ and the problem is still there for me (which makes sense since the package was built in December, and marcpayne's commit was on January).

[plikhari]

@geo909 No the package is not yet released. The latest release is 1.10.1 - however if you download the source you will get the latest commits. You will need to compile it yourself. On Arch Linux it is a breeze - search for build a package from source arch linux on your favourite search engine

[chepioq]

On Fedora the maintainer of conky has builded a rpm with the latest commit : http://koji.fedoraproject.org/koji/buildinfo?buildID=710499

You can ask the same think to the Arch Linux maintainer.

[geo909]

Thanks guys, I was a bit confused with the version numbers.