SEARCH

Enter your search query in the box above ^, or use the forum search tool.

You are not logged in.

#8701 2015-08-16 17:09:03

BraxnerM
Member
Registered: 2014-10-17
Posts: 22

Re: Conky v1.9 Thread

Sector11

I haven't seen this before ... the presumably initial run (update 0) is singularised, but the first standard run (update 1) is doubled up again (and all three in the same time-frame).

I had assumed the problem was confined to the initial run, i.e. update 0, in 1.9.1 from what I had seen in my outputs, but this would suggest it remains linked to the initial time-frame instead. So is there still a problem that might only show under some yet unspecified condition related to the initial time-frame, or is this something larger?

Has anyone tried additional runs using v1.10?

Offline

Be excellent to each other!

#8702 2015-08-16 17:37:33

Sector11
#!'er to BL'er
From: SR11 Cockpit
Registered: 2010-05-05
Posts: 15,667
Website

Re: Conky v1.9 Thread

Actually I missed that double 1 at the beginning.  sad
Not sure why my conky v1.9.1 isn't acting like yours.

I'm not a programmer .. but is there a way to pause the LUA script from running until after conky as run for 1 second?
Or am I missing the boat?

iami says it works in v1.10 I don't have that. (yet)


·  ↓   ↓   ↓   ↓   ↓   ↓  ·
BunsenLabs Forums now Open for Registration
·  ↑   ↑   ↑   ↑   ↑   ↑  · BL ModSquad

Offline

#8703 2015-08-16 18:41:03

iami
Member
Registered: 2013-09-06
Posts: 44

Re: Conky v1.9 Thread

I've tested it a bit more and it seems like it also has to do with improper exiting conky. But it's kinda inconsistent.

Now because these are quick test is just use the conky command in terminal and press cntrl + z to quit conky (ps: this is not how you kill conky, running pidof conky will show you they might still be running), after doing this a couple of times (starting, quitting, starting ....) i managed to get this output (and a likes)  cool  This is not that surprising (although technically shouldn't happen) since pidof conky indicates there are multiple conky instances running. Note this is in conky 1.10

counter  -   updates     -    second 
1	 - 	0	 - 	54
2	 - 	1	 - 	54
3	 - 	1	 - 	54
4	 - 	1	 - 	54
5	 - 	1	 - 	54
6	 - 	1	 - 	54
7	 - 	1	 - 	54
8	 - 	1	 - 	54
9	 - 	1	 - 	54
10	 - 	1	 - 	54
11	 - 	1	 - 	54
12	 - 	1	 - 	54
13	 - 	2	 - 	55
14	 - 	2	 - 	55
15	 - 	2	 - 	55
16	 - 	2	 - 	55
17	 - 	2	 - 	55
18	 - 	2	 - 	55
19	 - 	2	 - 	55
20	 - 	2	 - 	55
21	 - 	2	 - 	55
22	 - 	2	 - 	55
23	 - 	2	 - 	55

After running killall conky and assuring with pidof conky there are no instances running and starting the config again it goes back to the output from my previous post (always). I also managed to replicate the output from Sector11 (in conky 1.10) just by starting, quitting, starting, quitting ect... it appears rather random/unpredictable whether or not i get double/tripple/ ... /Sector11's output.

So to wrap it up:
if there is no conky running (eg pidof conky gives no result) i always get the output from my first post, if multiple conkies are running it screws up output like in the code from this post or output like Sector11 had.
Note: there is no actual problem if there are other conky config running with different config/lua files, but when i say multiple conkies i mean from the improper closing in the terminal by cntrl + z and starting the same config again.

@Sector11 : you can always put in

if tonumber(conky_parse('${updates}')) > 5 then return end

at the lua file as first line in the function. Not quite what you requested but close enough so it seems? (more complex solution would be to start a timer from the first time the lua script get called by conky, eg ${updates} == 0, and have a check similar to the above but this time from the timer in lua)

(i hope this post makes sense)

edit: nice bug find though

Last edited by iami (2015-08-16 18:55:58)

Offline

#8704 2015-08-16 19:32:52

BraxnerM
Member
Registered: 2014-10-17
Posts: 22

Re: Conky v1.9 Thread

iami

I tried to reproduce Sector11's output, and didn't manage it on my end. Re-reading your post, I tried again to no avail. I could not even get multiple instances of conky to show via 'pidof conky', until it dawned on me that you didn't actually kill off the conky's ... 'Ctrl+Z' merely sent a SUSPEND to the process, i.e. stopped the process, while I kept killing mine off. Once I tried it with STOPPED conkys still hanging about, I finally could reproduce Sector11's output.

So as an addendum to your post, it seems that the presence of STOPPED conkys interferes somehow, while properly killed off conkys seem to have no effect (... unless you managed to start a conky while the preceding version was still being killed?)

Which still leaves two questions on my end. First, how did Sector11 manage to get his output version in the first place? Second, the opening 'double-tap' within the identical time-frame still persists in v1.9.1 ... why?

Offline

#8705 2015-08-16 21:13:05

BraxnerM
Member
Registered: 2014-10-17
Posts: 22

Re: Conky v1.9 Thread

Since that whole STOPPED process thing kept bugging the hell out of me, I tried a different angle: I started three conkys in different shells ... here's the output from the first with added comments:

counter  -   updates     -    second 
1        -      0        -      12
2        -      1        -      12
3        -      2        -      13
4        -      3        -      14       <-- started 2nd conky 
5        -      3        -      15       <--  and here it is
6        -      4        -      15
7        -      4        -      16
8        -      5        -      16       <-- 2 conkys in parallel     
9        -      5        -      17
10       -      6        -      17      <-- started 3rd conky 
11       -      6        -      17      <-- should be 2nd instance
12       -      6        -      17      <-- 3rd one as expected
13       -      6        -      18      <--  a 4th ?? Yap ... no clue !!!!
14       -      7        -      18      
15       -      7        -      18      <-- 3 conkys in parallel
16       -      7        -      19
17       -      8        -      19      <-- killing off one shell
18       -      8        -      20      <-- leaves 2 running
19       -      9        -      20
20       -      9        -      21
21       -      10       -      21     <-- killing off 2nd shell
22       -      11       -      22     <-- clean as a whistle 

Let's speculate ...
First, this looks as though conky maintains a single list of named lua hooks, say, in the form of function calls via memory ref, and simply attaches an entry to that list upon the start of each new conky. Upon refresh, conky simply runs through the list, calling each referenced function ... hence the multiple instances.

Second, the behavior seems clean enough, in that killed conkys lead to their functions being removed from the list, i.e. no actual memory leak ... blatant guess work, of course :-)

Third, I haven't got the foggiest where that 4th instance call (update 6) comes from, but something like this happened again and again. My best guess would be something like the double-feature we've seen on start-ups.

Finally, seeing that the individual calls per update span multiple second ranges should follow from the fact that each lua-function instance individually calls conky to retrieve the second, so that one should be fine.

Now for the not so funny bit ... I tried this again, but this time changed the names of the configs for the 2nd and 3rd conky, as well as for the loaded lua scripts, and the called functions ... and multiple instances occured in each combo.

This would make it seem as though conky is maintaining a single 'lua hook list', to which lua functions are appended upon their designating hook-specs in the respective conky configs ... fine so far, except that each conky instance (running and stopped) contributes to this list, and all running conky-instances apparently call-up the entire list for execution upon their individual updates.

Let me put this differently:
If you run multiple instances of conky using lua-hooked functions, then they will ALL get updated whenever ONE of them gets updated!

Imaging, if you will, a combination of a lua-hooked clock, updating every second, and a bandwidth intensive script (wheather, rss,...) ... not a nice picture. Unnecessary resource waste aside, this can really screw up scheduled data-pulls, interval-dependent calculations called out of sync, stats, ...

Any thoughts?

Offline

#8706 2015-08-17 06:36:53

iami
Member
Registered: 2013-09-06
Posts: 44

Re: Conky v1.9 Thread

@addendum: you're right, should have stated it more clearly.

@" 'double-tap' within the identical time-frame", although it is speculation of course, it happens both in 1.9.1 and 1.10, i think this is a conky implementation bug because it's a consistent phenomena. Considering conky is certainly not bug free (Exec, exci, ... bug) this would be no surprise to me.

@first: this would be my first thought too but considering the conkies are different processes and as far as i know conky does not share things betweens it's instances i think the issue is more complex. But i must admit that this starts to hit the boundaries of my conky knowledge, so correct me if i'm wrong.

@third:  not a clue to be honest, my guess would be the same as yours.

Now for the not so funny bit ... I tried this again, but this time changed the names of the configs for the 2nd and 3rd conky, as well as for the loaded lua scripts, and the called functions ... and multiple instances occured in each combo.

This would be a great issue, i will try to reproduce it later today if i have the time. (Question: did you also rename the function name in the lua files?)

An other idea i would like to throw in are the (crappy) tolua++ library conky uses... as i've mentioned here: Conky Lua 5.3 support
The lua developer states the library is crap (Don't use tolua++, This is why)
I also know lua may have weird behaviour with the use of globals (eg your counter and updates veriable) so i tried putting adding

-- LUA script - barebones.lua

local counter = false
local updates = 0

function conky_main()
...
end

but it did not have any effect at all.

I don't know how your C/C++ knowledge is but if you feel confident enough you might want to start digging in de code eg llua.cc since this seems a rather technical issue. (my C/C++ skills are not up for it i'm afraid).

Will look more in depth at this issue later today or in the next days (depends if i find the time).

Offline

#8707 2015-08-17 07:53:44

BraxnerM
Member
Registered: 2014-10-17
Posts: 22

Re: Conky v1.9 Thread

iami ...

'conky does not share things between it's instances' ... I wouldn't expect them to. But this begins to feel like an unintentional linkage in the interface management between conky and lua.

I keep circling back onto the same issue, over and again. The way I read the outputs, suggests to me that the conky-hooked lua function has to be called up more than just once in order to explain the printed output, i.e. more often than the update cycle  for the specific conky instance can explain. Running another, separate, independent conky using a different config, in a different shell, calling a differently named (conky-hooked) lua function in a differently named script, could not possibly entail calling the function in the 'first' conky-shell. So the additional calls of the hooked-function in the first conky-shell, would have to be linked to the update-cycle in the second conky-shell. Fine, let's test it.

For the first conky, I used the same config/script combination as before, for the second (please note the differently named function ;-) ) ...

# conky configuration   -   barebones2.conky                                                                             
#background yes                                                
update_interval 3           
total_run_times 0                                               


lua_load /home/nat/bin/conky/scripts/barebones2.lua
lua_draw_hook_post test

TEXT
-- LUA script  -  barebones2.lua
function conky_test()
  if not counter then 
     counter = 0 
  end
  counter = counter + 3
end

The important change is the 'update_interval 3', i.e. the scripts run asynchronous. Output for the first script ...

counter  -   updates     -    second 
1        -      0        -      49
2        -      1        -      49
3        -      2        -      50      <-- started 2nd 
4        -      2        -      51      <-- and here we are
5        -      3        -      51
6        -      4        -      52      < -- clean skips, no additional calls
7        -      5        -      53      <--  update cycle for 2nd
8        -      5        -      54      <--  forces update-cycle in 1st
9        -      6        -      54
10       -      7        -      55     <-- again clean
11       -      8        -      56     <--  forced update cycle
12       -      8        -      57     <--  turns up like a charm
13       -      9        -      57

All right, no let's turn the update_interval the other way around, i.e. 1st gets 3, 2nd gets 1. Output for the first script ...

counter  -   updates     -    second 
1        -      0        -      03
2        -      1        -      03
3        -      2        -      06    <--  1st update-cycle
4        -      2        -      08    <--  2nd called for the first time
5        -      2        -      09    <--  and again
6        -      3        -      09    <--  1st update-cycle
7        -      3        -      10    <--  2nd again
8        -      3        -      11    <--  ...
9        -      3        -      12

Yes, I do think there is a shared linked there somewhere.  I repeat: When ONE conky with a hooked-lua function is updated, then ALL conky instances with hooked-lua functions are updated. qed    ]:D

As for c/c++, reviewing conky/lua impementations ... you're joking, right. I can barely handle this stuff.

Offline

#8708 2015-08-17 10:38:03

iami
Member
Registered: 2013-09-06
Posts: 44

Re: Conky v1.9 Thread

I can confirm your results (on 1.10) and did some extra tests but they gave no additional information. I can only come to the same conclusion as you did:

I repeat: When ONE conky with a hooked-lua function is updated, then ALL conky instances with hooked-lua functions are updated. qed

I suggest you file a bug report on the github.

'conky does not share things between it's instances' ... I wouldn't expect them to. But this begins to feel like an unintentional linkage in the interface management between conky and lua.

I know but i, quietly, wished something else came up. This seems like it might be a very _nasty_ and technical bug to fix and if it is related to tolua++ (a deprecated library) it may require _a lot_ of work to switch libraries.

As for c/c++, reviewing conky/lua impementations ... you're joking, right. I can barely handle this stuff.

I was just hoping considering this might take a while, if ever, some one will fix this issue. Nice debugging though smile And i'm very surprised this issue did not come up any earlier.

As for the bug fix from 1.9 -> 1.9.1 (double calling) i've only found this commit which is related to the issue: Commit since it's filed by arclance (which is active on this forum), he might want to way in on this issue.

edit: note my use of "might" ect, i don't know the technical reason of it happening and the fix for 1.9 -> 1.9.1 was minor. in terms of code change

Last edited by iami (2015-08-17 10:55:51)

Offline

#8709 2015-08-18 03:24:44

arclance
#! Die Hard
Registered: 2012-03-29
Posts: 987

Re: Conky v1.9 Thread

iami wrote:

As for the bug fix from 1.9 -> 1.9.1 (double calling) i've only found this commit which is related to the issue: Commit since it's filed by arclance (which is active on this forum), he might want to way in on this issue.

This is the bug report associated with that commit.
I don't know much about the language but I believe that the fix was just to move the code that runs the Lua part of conky out of "static void draw_text(void)".
Since the shaded text in conky is made by drawing the text twice (once in the shade color offset by a certain number and then again in the normal color at the normal position) putting it there caused it to run twice when "draw_shades yes" is set.

Offline

#8710 2015-08-18 05:39:35

BraxnerM
Member
Registered: 2014-10-17
Posts: 22

Re: Conky v1.9 Thread

iami ... I'm not sure you're going to like this.

Since something kept bugging me about this whole 'update-cycle' thing ... well an old mentor of mine kept insisting that whenever you get such an itch, 'assume all your assumption are wrong, and see where that gets you'.

I used pretty much the same set-up as before (2 asynchronous conkys, different shells, ...), except that I removed the 2nd conky's lua-hook completely, i.e. ...

# conky configuration  -  barebones3.conky                                                                             
update_interval 1           
total_run_times 0                                              

TEXT

The output of the first conky ...

counter  -   updates     -    second 
1        -      0        -      29
2        -      1        -      29
3        -      2        -      32   <-- clean so far
4        -      3        -      35   <-- started 2nd conky shell
5        -      3        -      36   <-- and what do we have here?
6        -      3        -      37
7        -      3        -      38
8        -      4        -      38   <-- by now this looks familiar
9        -      4        -      39   <-- doesn't it
10       -      4        -      40

So, whenever one conky updates, all conkys with lua-hooked functions update?

Let's alter the 1st conky, so as to include a second display in a simple window, ...

# conky configuration  -  windowed_barebones.conky                                                                                                                               
update_interval 3           
total_run_times 0                                               
own_window      yes 
minimum_size    100 100

lua_load /home/nat/bin/conky/scripts/barebones.lua
lua_draw_hook_pre main 

TEXT
${color #FCD97B}${time %S}$color

and run it all on its own ...

counter  -   updates     -    second 
1        -      0        -      07
2        -      0        -      07
3        -      1        -      07
4        -      1        -      07
5        -      1        -      07   <-- not promising, it it
6        -      1        -      07
7        -      2        -      10  
8        -      2        -      10
9        -      3        -      13   <-- things seem to settle down
10       -      4        -      16
11       -      5        -      19
12       -      6        -      22
13       -      7        -      25
14       -      7        -      25   <-- whoops
15       -      8        -      28

In other words, one conky can multi-update all by itself ... lovely.

Fine, now let's run both conkys in their respective shells ... output of the 1st ...

counter  -   updates     -    second 
1        -      0        -      39
2        -      0        -      39
3        -      1        -      39
4        -      1        -      39
5        -      1        -      39   <-- really???
6        -      1        -      39
7        -      1        -      39
8        -      2        -      42   
9        -      3        -      45   <-- started 2nd shell
10       -      3        -      45
11       -      4        -      48   <-- a stuttering update-cycle?
12       -      5        -      51
13       -      5        -      51
14       -      6        -      54
15       -      7        -      57
16       -      7        -      57
17       -      8        -      00
18       -      8        -      00
19       -      9        -      03   <-- killed 2nd shell
20       -      10       -      06
21       -      11       -      09

In short, I think I better amend for my earlier assertion ... I can't maintain that the problem appears to reside solely with the interface between conky and lua. Instead, this appears more a conky problem than anything else, and frankly, I don't quite see how to even nail it down. Mind you, the earlier results were clear cut and clean, and will have to be addressed, but this points to something far nastier.

Because of this, I have not filed a bug report yet, since I frankly don't even know to phrase this mess. I would really appreciate some more active help from more experienced hands.

Offline

#8711 2015-08-18 06:27:10

iami
Member
Registered: 2013-09-06
Posts: 44

Re: Conky v1.9 Thread

@arclance: thanks for the info

@BraxnerM: it's getting worse and worse (so it seems), a thing that bothers me is: i have usually 9 conkies running, 2 lua graphs which contains 500 values each and add + discard 1 value every update. -> The bars move only once a second -> implying they only get called once a second (update_interval = 1 for 5 out of 9 configs, including configs with the graphs)  but this does not compute with the findings here. But i must say i did not investigate it nor had a look at the lua code itself which may discard the values or something on those lines, but that's what is itching me at the moment about this issue.

Unfortunately i won't have time to play with conky (and trying to investigate this issue extensively) until tomorrow or Thursday so i'm afraid i can't be of any help at the moment.

'assume all your assumption are wrong, and see where that gets you'.

That is indeed a good thing to do, and as it shows here was the right thing to do.

Last edited by iami (2015-08-18 06:28:38)

Offline

#8712 2015-08-18 06:56:29

BraxnerM
Member
Registered: 2014-10-17
Posts: 22

Re: Conky v1.9 Thread

iami ...
As to multiple conkys with lua functions (at least if hooked) and the update issue: As far as I can tell from the above try-outs, it appears that there is a distinct difference between a conky updating a display, and a conky updating a hooked lua call ... which I of course forgot to mention.

When you run the above conky config with the second display, you'll see that the window contents are updated to schedule i.e. only every 3 seconds, while the printed output in the shell clearly confirms that the hooked lua function is called far more often than that.

This would suggest that your setup of 9 conkys drains far more resources than necessary, and will likely accumulate erroneous data via those extra update calls.

To test and limit the effect--it would be nice to have some baselines here--I would suggest a two step approach. First, you might try and introduce the method used so far, i.e. a counter-based tracking, into your hooked functions, to see if, and when, they update. From there you could check to see if unwanted data points are entered into your tables. Second, you could use a simple, though ham-fisted buffer-variable as a cutoff in your hooked function, say along the lines of ...

...
if ( lastUpdate != tonumber(conky_parse('${updates}')) ) then
    lastupdates = tonumber(conky_parse('${updates}'))
    ... run your needed update
end

This way, at least, you could easily enough suppress unwanted update runs, thereby securing your data, etc., against unwanted additions/distortions, while at least somewhat limiting the overhead.

Offline

#8713 2015-08-18 12:42:36

arclance
#! Die Hard
Registered: 2012-03-29
Posts: 987

Re: Conky v1.9 Thread

@iami & BraxnerM
Certain things can trigger a conky update other than it being "on time".
Two I know of are dragging a window across a conky (this forces updates as the window manager needs to redraw constantly) and changing workspaces in some window managers.
If any of your conky windows overlap it might be something related to the dragging thing.
I have three conky windows on one computer that don't overlap and never had anything like this happen with v1.9.1 except the previously mentioned "draw_shades yes" bug.

Last edited by arclance (2015-08-18 16:07:57)

Offline

#8714 2015-08-18 18:19:09

BraxnerM
Member
Registered: 2014-10-17
Posts: 22

Re: Conky v1.9 Thread

@arclance ...
Thanks for the input ... the GUI conditions you pointed out should have been obvious, but I actually didn't think of them. While they therefore broaden the area of concern, I don't think that they match the conditions I observed. First, if you review the configs and scripts used in the preceding postings, you'll notice that the majority was used without any windowing on conky's part, just cli stuff run in (graphically non-overlapping) shells. Only the last bit used a window displaying the second of the last update call. Furthermore, and I can only go by my impressions on this, it seems that there is a distinct separation between conky (re-)drawing a window, and conky updating a hooked lua function.

Any cascading update interference question aside though, I think your point is very important by itself with regards to iami's conky's adding and removing data points into/from (i assume) tables. Any unchecked run of hooked functions inserting/removing data triggered by GUI events instead of scheduled updates would inevitably distort the data represented in the tables.

Ensuring proper data handling would thus necessitate an in-function check on the origin of the update, and that is something that I have not seen routinely done in any hooked functions I have come across.

Offline

#8715 2015-08-18 18:43:37

arclance
#! Die Hard
Registered: 2012-03-29
Posts: 987

Re: Conky v1.9 Thread

BraxnerM wrote:

Ensuring proper data handling would thus necessitate an in-function check on the origin of the update, and that is something that I have not seen routinely done in any hooked functions I have come across.

I do it in my scripts because dragging windows across the conky windows triggers updates.
It is very obvious what must be happening looking at a CPU graph done completely with LUA while dragging the window.

Are you two loading the same lua file in each conky?
Try making a copy of it with a different name for each conky you start.
If that changes nothing also try doing that and change the name of the function you call in conky to something different for conky.

Last edited by arclance (2015-08-18 19:00:38)

Offline

#8716 2015-08-18 18:57:27

BraxnerM
Member
Registered: 2014-10-17
Posts: 22

Re: Conky v1.9 Thread

@arclance ...

arclance wrote:

Are you two loading the same lua file in each conky?
Try making a copy of it with a different name for each conky you start.
If that changes nothing also try doing that and change the name of the function you call in conky to something different in for conky.

To answer in order: No. Done. And done.

These possibilities were already covered in the developing discussion above.

Offline

#8718 2015-08-20 07:12:25

iami
Member
Registered: 2013-09-06
Posts: 44

Re: Conky v1.9 Thread

@arclance: thanks for the update-dawing info, nice to know. Ps: you may want to close the border issue on github since the fix is merged.

@my lua graphs: i didn't know they weren't drawing "live" but even so this would suggest the graphs would make big jumps since between the 1 second conky updates the graphs visually there would be many values added by the numerous lua updates in that 1 second time frame. While i did not check the lua scripts themselves (for discarding, ect...) this seems not the case on first sight. The following findings my indicate why that is. (and they overlap with at least 1 other conky)

I did some further tests (Conky 1.10) these are my findings:
- Running the configs with an own window does not trigger the additional updates aside from the double at the start
- Running the configs without own window triggers extra unwanted updates as we found above

Numbers (counter - updates):

Updates 1/sec; lua1 (window):
1306	 - 	1301
1252	 - 	1248
1315	 - 	1312

Updates 1/sec: lua2 (window):
1283	 - 	1280
1292	 - 	1281
1290	 - 	1274

Update 0.2/sec; lua1 (window):
6305	 - 	6288
6273	 - 	6220
6270	 - 	6248

Update 1/sec: lua1 (no window):
3129	 - 	1035
3272	 - 	1035
3248	 - 	1044

Theoretically they should match (given the start up double-update bug they may have a difference of 2) but they don't. Although it does not seem too bad when running in with their own window for more precise or critical measures this is annoying/wrong. All test were executed in parallel and no other conky instance other than the those above were running. All the windows were overlapping but only 1 was always on top.
Lua1 uses local variables, lua2 uses global variables.
Do not mind the difference in updates, i've started and stopped the conky instances at different times.

I do not have an explanation for the difference in counter and updates for the windowed instances, this needs further investigation (maybe forced window updates?). When not having the own window the behaviour of conky just seems wrong as we found out earlier.

edit: BraxnerM can you confirm these finding?

===========================================================================================

I might be doing something wrong but i can not reproduce your finding, in Conky 1.10, from http://crunchbang.org/forums/viewtopic. … 88#p437088
Conkies with their own window always have correct (see tests above) behaviour, and do not influence conkies without window (eg launching a conky without hooks but with window does not affect running a conky without window and hooks).
What i can confirm is that running 2 conkies without window, one with hook and one without hook will result in double updates as you've mentioned.

So this seems like it's not a lua issue, but rather an update issue when conkies don't have their own window or something along those lines. If it was pure lua the config without lua hooks should not influence the conky with the lua hooks.

Last edited by iami (2015-08-20 13:01:36)

Offline

#8719 2015-08-20 16:29:09

arclance
#! Die Hard
Registered: 2012-03-29
Posts: 987

Re: Conky v1.9 Thread

iami wrote:

- Running the configs with an own window does not trigger the additional updates aside from the double at the start

I believe this double run at the start is to seed the "${cpu_X}" variables with data if they are used in a conky so they don't return blank values on the first run like they used to.
The extra run still happens even if you don't call them but does nothing in that case.

iami wrote:

I do not have an explanation for the difference in counter and updates for the windowed instances, this needs further investigation (maybe forced window updates?). When not having the own window the behaviour of conky just seems wrong as we found out earlier.

If you mean you are using "own_window no" (you don't specify what "not having the[ir] own window" means setting wise here) I believe this will cause all conkys using that setting to share the same window (possibly the root window).
Since the Lua scripts in conkys drawing to that window run every time the window is redrawn and every time any conky updates that window it causes a redraw of that window all the "own_window no" conkys Lua scripts would run every time any of the conkys updates.

Last edited by arclance (2015-08-20 18:09:13)

Offline

#8720 2015-08-20 18:06:52

iami
Member
Registered: 2013-09-06
Posts: 44

Re: Conky v1.9 Thread

arclance wrote:

I believe this double run at the start is to seed the "${cpu_X}" variables with data if they are used in a conky so they don't return blank values on the first run like they used to.
The extra run still happens even if you don't call them but does nothing in that case.

Interesting, would have never found this.

arclance wrote:

If you mean you are using "own_window no" (you don't specify what "not having the[ir] own window" means setting wise here) I believe this will cause all conkys using that setting to share the same window (possible the root window).
Since the Lua scripts in conkys drawing to that window run every time the window is redrawn and every time any conky updates that window it causes a redraw of that window all the "own_window no" conkys Lua scripts would run every time any of the conkys updates.

That was indeed what i meant, but indeed should have stated it explicitly.
I was indeed thinking in that direction too (since it also happened with configs without lua hooks) but i did not find a way to test it. Good to know smile

Offline

#8721 2015-08-21 05:52:03

BraxnerM
Member
Registered: 2014-10-17
Posts: 22

Re: Conky v1.9 Thread

arclance ...
Thank's again for taking the time to answer. I think you provided the right insight, when you wrote that ..."

arclance wrote:

I believe this will cause all conkys using that setting to share the same window (possibly the root window).
Since the Lua scripts in conkys drawing to that window run every time the window is redrawn and every time any conky updates that window it causes a redraw of that window all the "own_window no" conkys Lua scripts would run every time any of the conkys updates.

I think this explains the cascading updates we saw in the window-less conkys using hooked lua-functions.

@iami ... I reckon this was the bit that conkys 'shared' after all, the bridge we didn't see  smile

As to your not being able to confirm my previously posted observations, I think that probably resulted from two misunderstandings. To clarify, I consider the majority of my post as reproducible. The first part you confirmed yourself (window-less conkys cross-updating), and arclance provided the explanation (shared window, even if window-less). The second part (specification and run of a solitary windowed_barebones.conky) remains clear, and the observed multi-updates are, once again, explained through arclance's help, as likely originating with GUI-triggers.

The final part was a combined run of a windowed_barebones.conky as 1st, and a barebones3.conky as 2nd, which I referenced as "let's run both conkys in their respective shells ... output of the 1st" ... which is probably the iffy bit, since, re-reading this, it sounds as though the provided output might belong to window-less one, instead of the windowed version ... my muddle, sorry mate. The second misunderstanding was entirely mine, in mis-reading the multi-updates in the windowed-versions output as possible cascading updates induces by the barebones3.conky run ... it can be difficult to re-produce a misunderstanding big_smile

Anyway, thanks to iami's and arclance's help, I now consider the entire issue as resolved in substance.

The only concern that remains to me, is the best way to control my update depending data-collection, i.e. how best to avoid multiple entires due to, say, GUI-triggered updates. Is 'buffering' the update-readout from conky the most sensible way?

Offline

#8722 2015-08-21 07:48:46

fuzamaru
New Member
Registered: 2015-08-21
Posts: 2

Re: Conky v1.9 Thread

[sorry for bad english]
excuse me smile
this is my first post and  i wanna ask about conky window settings

[OS = linux mint 17.2 Linux Mint Cinnamon]
So, i wanna show conky analog clock in front of all programs (with "own_window_type panel") but i have trouble on the tranparency
if the color behind the clock is dark the clock is shown, but if the color behind the clock is white, the clock is gone (hiden)
24297gz.png

This is the script:

# Performance Settings
update_interval 1
double_buffer yes
no_buffers yes
background no

# Window Settings
own_window yes
own_window_type panel
own_window_transparent yes
own_window_argb_visual yes
own_window_argb_value 200
#own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager
#disable_auto_reload 1

# Window border
draw_shades no
#draw_borders no
draw_graph_borders no

# Size and position
minimum_size 185 185
gap_x 0
gap_y 50
alignment br

# Lua Скрипты
lua_load ~/.conky/just_another_clock/lua/imlib_clock.lua

TEXT
${lua imlib_clock atolm 200 95 95}

i 've tried changing several window settings code, but no one succeed
_____________________________________________________________________
Test 1

own_window_type panel
own_window_transparent no        # with no / yes , same result
own_window_argb_visual no
#own_window_argb_value 200 

vgplbo.png
______________________________________________________________________
Test 2

own_window_type panel
own_window_transparent no
own_window_argb_visual yes
own_window_argb_value 200         # changing the value just changing the opacity

2ylof8h.png
______________________________________________________________________
Analog Clock conky & lua source : devianart

How can i get round analog clock with better opacity?
Can i set conky configuration with round panel windoes_own_type?
Or should i change the lua file to get round clock? (i dont know anything about lua language)

Thanks for your attention big_smile

iami wrote:

Your images do not work, you have copy pasted the names of the images but we can not see them. You have to upload them to a website and give us the link or make a thumbnail. Maybe some one (Sector11?) knows a tutorial to do this.

So you want the clock to be on top all the time and have a transparent background? I'm using cinnamon too and used the folowing settings for the cairo_clock_rc:

# Window Settings
own_window yes
own_window_transparent false
own_window_type normal
own_window_hints undecorated,above,sticky,skip_taskbar,skip_pager
own_window_argb_visual yes
own_window_argb_value 0

(replace the current window settings with the one i gave, the clue is to use the "above" window hint)

edit: this won't work for the imlib version since the own_window_argb_value value also sets the alpha value of the clock itself making it invisible if you set it to 0.

thanks. i ve uploaded to tinypic and image is shown

yeah, on top all the time, i dont mind if the clock transparent or no
I want the clock is round without black color which make it square like test 1 screenshot.
now i can get rid of black color with transparency, but the clock is gone if behind the clock is white, like my first screenshot
_____________
i ve tried using your code and this is the screenshot:
2ms4oea.png
and i dont know why your code still have same transparency problem
i change argb value to 250, the black color is shown again like test  1 screenshot

any ideas? sad

Last edited by fuzamaru (2015-08-21 19:18:47)

Offline

#8723 2015-08-21 09:31:20

iami
Member
Registered: 2013-09-06
Posts: 44

Re: Conky v1.9 Thread

Your images do not work, you have copy pasted the names of the images but we can not see them. You have to upload them to a website and give us the link or make a thumbnail. Maybe some one (Sector11?) knows a tutorial to do this.

So you want the clock to be on top all the time and have a transparent background? I'm using cinnamon too and used the folowing settings for the cairo_clock_rc:

# Window Settings
own_window yes
own_window_transparent false
own_window_type normal
own_window_hints undecorated,above,sticky,skip_taskbar,skip_pager
own_window_argb_visual yes
own_window_argb_value 0

(replace the current window settings with the one i gave, the clue is to use the "above" window hint)

edit: this won't work for the imlib version since the own_window_argb_value value also sets the alpha value of the clock itself making it invisible if you set it to 0.

Last edited by iami (2015-08-21 11:12:41)

Offline

#8724 2015-08-21 14:30:15

arclance
#! Die Hard
Registered: 2012-03-29
Posts: 987

Re: Conky v1.9 Thread

BraxnerM wrote:

The only concern that remains to me, is the best way to control my update depending data-collection, i.e. how best to avoid multiple entires due to, say, GUI-triggered updates. Is 'buffering' the update-readout from conky the most sensible way?

I do this to protect collected data in my lua scripts.

--#### Setup Global Variables ####
if tonumber(conky_parse('${updates}')) < 2 then --# don't reset these global variables when changes are made to the lua script
	previousEpoch = os.time() --# initialize previous epoch (use to prevent graph tables from being screwed up when other windows are moved across the conky window)
end --# if tonumber(conky_parse('${updates}')) < 2 then

function conky_main() --# main function controls everything else
	local newEpoch = os.time()
	if previousEpoch < newEpoch then
		"Collect Data in Global Variables Here"
	end --# if previousEpoch < newEpoch then
	if previousEpoch < newEpoch then
		previousEpoch = newEpoch
	else
		print("error: epoch check warning old:"..previousEpoch.." new:"..newEpoch)
	end --# if previousEpoch < newEpoch then
end-- end main function

It compares the current output of "os.time()" (the epoch time in seconds) to the value in "previousEpoch".
If the current time is greater than "previousEpoch" is collects and records a new data point otherwise it does nothing.
This checks the time using a Lua function so it does not depend on any of conkys internal update tracking being accurate.

Since Lua does not report epoch time more accurately than one second resolution this won't work for update intervals less than one second.

Last edited by arclance (2015-08-21 14:33:04)

Offline

Help fund CrunchBang, donate to the project!

#8725 2015-08-21 20:48:12

arclance
#! Die Hard
Registered: 2012-03-29
Posts: 987

Re: Conky v1.9 Thread

fuzamaru wrote:

i ve tried using your code and this is the screenshot:

and i dont know why your code still have same transparency problem
i change argb value to 250, the black color is shown again like test  1 screenshot

any ideas? sad

The transparency problem comes from the way the lua script draws images using imlib2.

Adding this line to the script "imlib_context_set_blend(0)" like this may make it work when using a compositor.

	-- combine the clock
	local buffer = imlib_create_image(w_img, h_img)
	imlib_context_set_image(buffer)
	imlib_image_set_has_alpha(1)
	imlib_image_clear()
	imlib_context_set_blend(0)
	imlib_blend_image_onto_image(

Setting "imlib_context_set_blend(0)" when using argb transparency (using a compositor) is the fix for this that was used in conky v1.10.
It does not work correctly when set to "1" which is the default in conky v1.9.1 when using argb transparency.

Offline

Board footer

Powered by FluxBB

Copyright © 2012 CrunchBang Linux.
Proudly powered by Debian. Hosted by Linode.
Debian is a registered trademark of Software in the Public Interest, Inc.
Server: acrobat

Debian Logo