conky-development Mailing List for Conky

Hey!

 

New message, please read <http://zoomincinema.in/should.php?qjm>

 

ho...@ma...

Hello!

Maybe Conky should follow the proposal of freedesktop.org
(http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)
and store personal configuration in XDG_CONFIG_HOME (default to
~/.config). Concretely, according to this specification, the
configuration file should be ~/.config/conky/conkyrc and not ~/.conkyrc.
This way has some advantages. First, it avoids that HOME are cluttered
by lots of configuration files and directories. Moreover, group together
all configuration and data files, permits to the user to copy its
complete configuration easily.
Regards.

-- 
Sylvhem
http://lepubdelobservateur.fr
ID OpenPGP : 01A4730E

I was experimenting with offlining cpu cores on a Sandy Bridge quad-core
processor and found that conky would segfault depending on which cores
were offline.  I was using the /sys/devices/system/cpu/cpu*/offline
interface to add and remove cores.

The problem is that get_cpu_count() uses /proc/stat to count how many CPUs
are present and allocate structure memory accordingly.  Only online cores
show up in my /proc/stat so not enough memory was being allocated to handle
the highest possible cpu index.

For example, I made cpu0 online, cpu1 offline, cpu2 online, and cpu3 offline.
get_cpu_count() only allocated enough memory for 2 cpus and would segfault
when I asked for information about the "third" cpu2 index.

According to the kernel's Documentation/cputopology.txt,
/sys/devices/system/cpu/present shows how many cpus have been identified
as being present on the system.  I modified get_cpu_count() to use this
file instead of /proc/stat to determine how much structure memory to
allocate.  That way, all possible cpu indexes are covered, regardless
of which cpus are actually online at any given time.

I've attached the sample conkyrc file that I used to test.  I've also
attached a patch if you're interested in this change.  I'm using a 3.10
kernel and I do not know how portable /sys/devices/system/cpu/present
is between past and future kernels.  I adjusted the patch to apply
cleanly against linux.cc from git but I have only tested it with conky
1.9.0.

In my patch, get_cpu_count() no longer calls determine_longstat().
I haven't noticed any problems, but I have not verified that
determine_longstat() doesn't have any side effects that persist
beyond get_cpu_count().

Hello,

I was surprised to see that the battery status is refreshed only a few
times per a minute, although everything else is updated instantly.

I dived into the source and found this in src/linux.c around line 1632

/* don't update battery too often */
    if (current_update_time - last_battery_time[idx] < 29.5) {
        set_return_value(buffer, n, item, idx);
        return;
    }

It appears (through github lame) that this has been there always, so I
wasn't able to determine the motivation behind it.
Could anyone explain, what was the original motivation for this piece of
code? Maybe the original problem isn't present in modern Linux anymore.
i3status checks the battery info every second and I had no issues.

I really think this should be mentioned in the documentation, it puzzled me
for a quite a while.
I'd like to propose that this magic 29.5 value could be set to something
else in .conkyrc. I do agree that it doesn't need to be checked too often,
but half a minute is too much IMHO.

Kind regards,

Ondrej Grover

No objections from me. If I can make time, I will. I'm travelling until
next week, so perhaps I can do it when I return.
On Jun 19, 2013 1:27 PM, "Bas Pape" <ba...@gm...> wrote:

> Hi all,
>
> Maybe it's time for a release again? There've been quite a few changes
> (33 commits, one pull request I just opened), in my opinion release
> worthy; if not only to get bugfixes out there a bit faster. Any
> pressing issues that need fixing? If i'm not mistaken the lua building
> mishap got fixed and haven't heard of anything else, but IRC tends to
> be quiet these days.
>
> --
> Tucos
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Conky-development mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/conky-development
>

Hi all,

Maybe it's time for a release again? There've been quite a few changes
(33 commits, one pull request I just opened), in my opinion release
worthy; if not only to get bugfixes out there a bit faster. Any
pressing issues that need fixing? If i'm not mistaken the lua building
mishap got fixed and haven't heard of anything else, but IRC tends to
be quiet these days.

--
Tucos

On 01/02/13 Pavel Labath <pa...@ce...> wrote:
>All in all, it looks fairly ok. I'll try to have a closer look at this
>stuff over the weekend and, hopefully, merge it.


Status?

On 03/02/13 James Morris <ja...@jw...> wrote:
>
>https://github.com/brndnmtthws/conky/commit/96935e8221ec6b7b83aa8b5f9ad13c331217511c
>
>The commit is broken. I'm reluctant to 'fix' it due to not knowing how
>my previous alteration to the same file broke things - it obviously
>must have because otherwise someone wouldn't have altered it and called
>it a fix.
>
>Here are the before and after lines from
>cmake/ConkyPlatformChecks.cmake:
>
>-pkg_search_module(LUA REQUIRED lua5.1 lua-5.1 lua=5.1)
>+pkg_search_module(LUA REQUIRED lua>=5.1 lua<5.2 lua-5.1>=5.1
>lua-5.2<5.2 lua5.1>=5.1 lua5.1<=5.2)
>
>As you can see, the tests are re-ordered. My commit (the 'before' line
>above) re-ordered the tests from this:
>
>pkg_search_module(LUA REQUIRED lua>=5.1 lua-5.1>=5.1 lua5.1>=5.1)
>
>I explicitly re-ordered them because lua can be any version, while
>lua5.1 can only be lua5.1 (same for lua-5.1.) Additionally, I also
>check for a explicit version, it must be equal to version 5.1, not
>lesser or greater.
>
>Conky master will not build against LUA 5.2.
>
>pkg_search_module(LUA REQUIRED lua>=5.1 lua<5.2 lua-5.1>=5.1
>lua-5.2<5.2 lua5.1>=5.1 lua5.1<=5.2)
>
>The above line fails because as soon as pkg_search_module finds one of
>the conditions satisfied it doesn't test the rest (sorry forgotten the
>jargon term for this behaviour, C if statements do it this way too).
>
>Arch Linux:
>$ pkg-config lua --modversion
>5.2.1
>$ pkg-config lua5.1 --modversion
>5.1.5
>pkg-config lua-5.1 --modversion
>Package lua-5.1 was not found in the pkg-config search path.
>Perhaps you should add the directory containing `lua-5.1.pc'
>to the PKG_CONFIG_PATH environment variable
>No package 'lua-5.1' found
>

Does this not make any sense to anyone?

https://github.com/brndnmtthws/conky/commit/96935e8221ec6b7b83aa8b5f9ad13c331217511c

The commit is broken. I'm reluctant to 'fix' it due to not knowing how
my previous alteration to the same file broke things - it obviously
must have because otherwise someone wouldn't have altered it and called
it a fix.

Here are the before and after lines from
cmake/ConkyPlatformChecks.cmake:

-pkg_search_module(LUA REQUIRED lua5.1 lua-5.1 lua=5.1)
+pkg_search_module(LUA REQUIRED lua>=5.1 lua<5.2 lua-5.1>=5.1
lua-5.2<5.2 lua5.1>=5.1 lua5.1<=5.2)

As you can see, the tests are re-ordered. My commit (the 'before' line
above) re-ordered the tests from this:

pkg_search_module(LUA REQUIRED lua>=5.1 lua-5.1>=5.1 lua5.1>=5.1)

I explicitly re-ordered them because lua can be any version, while
lua5.1 can only be lua5.1 (same for lua-5.1.) Additionally, I also
check for a explicit version, it must be equal to version 5.1, not
lesser or greater.

Conky master will not build against LUA 5.2.

pkg_search_module(LUA REQUIRED lua>=5.1 lua<5.2 lua-5.1>=5.1
lua-5.2<5.2 lua5.1>=5.1 lua5.1<=5.2)

The above line fails because as soon as pkg_search_module finds one of
the conditions satisfied it doesn't test the rest (sorry forgotten the
jargon term for this behaviour, C if statements do it this way too).

Arch Linux:
$ pkg-config lua --modversion
5.2.1
$ pkg-config lua5.1 --modversion
5.1.5
pkg-config lua-5.1 --modversion
Package lua-5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua-5.1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua-5.1' found

On 30/01/13 23:42, James Morris wrote:> Ah yes, that makes a lot of
sense, I hadn't really delved in deep to
> look at what is happening with the creation of conky objects. I'll
> use a counter incremented on calls to jack_init and decremented
> in jack_close, and only call jack_client_close when the counter reaches
> zero (unless conky already has a mechanism for this?).
No mechanism (in the 1.9 branch), as you have already figured out.

>> Also I find that semaphore thingy quite strange. What exactly are you
>> trying to achieve there?
>
> My grasp of multi-threading is a bit weak, so that's just something
> I've taken from another project[1]. jack_shutdown_cb() is called by
> JACK[2] never by conky so the semaphore is there to cause this
> communication between different process threads to hopefully happen in
> a thread safe manner!
You should read up on cargo cult programming
<http://en.wikipedia.org/wiki/Cargo_cult_programming>. Then, try to
avoid it. :)


On 31/01/13 01:57, James Morris wrote:
> Since many of the functions we're using to obtain information
> about the JACK server require registration as a client we need to
> know when we no longer are a JACK client otherwise we'll get
> the dreaded sig-segv - which considering conky's main task is NOT as a
> JACK client, would be poor going.
Segfaults are bad irrespective of whether something is your main purpose
or not.

> The JACK client should be opened just the once - by the first object
> which needs to, but only closed when conky exits. Otherwise if the
> only JACK object exists within a LUA script, the JACK client will be
> opened then closed on every update, which is unacceptable (it causes
> pops + clicks on my system).
> 
> So I've removed the call to jack_close() from free_text_objects() in
> core.c and placed it near the end of main() in conky.c. It's a lot more
> sensible and follows the normal way of doing things.
I figured this will come up. I do not particularly like this behavior,
but as pretty much every object in conky does this, i cannot really rub
you down for it. :D
However, I do intend do get rid of this stuff in the 2.0 release.

All in all, it looks fairly ok. I'll try to have a closer look at this
stuff over the weekend and, hopefully, merge it.

Cheers,
pl

On 30/01/13 Pavel Labath <pa...@ce...> wrote:

>I've tried to wrap my head around your code, but I cannot seem to
>figure out what it is doing. Maybe you could give a rough outline of
>what it is supposed to do. Especially, focus on the jack_close() call,
>because I think there may be a problem there. You seem to the close
>when *any* jack object is destroyed (as opposed to the *last* object).
>This could be the source of your troubles since the $if_jack_active
>object is destroyed as soon as conky_parse terminates. (at least I
>think it is, feel free to verify).


The JACK client should be opened just the once - by the first object
which needs to, but only closed when conky exits. Otherwise if the
only JACK object exists within a LUA script, the JACK client will be
opened then closed on every update, which is unacceptable (it causes
pops + clicks on my system).

So I've removed the call to jack_close() from free_text_objects() in
core.c and placed it near the end of main() in conky.c. It's a lot more
sensible and follows the normal way of doing things.

All my mistakes anyway... 

:-)


James.

On 30/01/13 James Morris <ja...@jw...> wrote:
>On 30/01/13 Pavel Labath <pa...@ce...> wrote:
>>On 30/01/13 14:34, James Morris wrote:
>>> On 30/01/13 James Morris <ja...@jw...> wrote:
>>>> Hi,
>>>>
>>>> Just sent a pull request on github for my latest changes.
>>>>
>>>> Aside from the omission of 'experimental' time data, and server
>>>> control (stop/start/etc), pretty much all data is available.
>>>>
>>>> Added documentation and fixed problems with conkyrc reload.
>>>>
>>>> cheers,
>>>> james.
>>> 
>>> 
>>> hmmm, just found an odd problem with code like this within lua:
>>> 
>>> 	if conky_parse("${if_jack_active}1${else}0${endif}") == "1"
>>> then print("jack active")
>>> 	else
>>> 		print("jack not active")
>>> 	end
>>> 
>>> init_jack is called on every update but my flag to prevent
>>> re-registering of the jack client seems to be ignored when called
>>> from lua.
>>> 
>>> think this is what stumped me the other week giving me cold feet
>>> from the prospect it might be a threads issue... is lua processing
>>> done in a different thread or something? or is my logic for
>>> preventing re-registration of conky as a jack client flawed????
>>> 
>>> james.
>>> 
>>
>>Hi,
>>
>>I've tried to wrap my head around your code, but I cannot seem to
>>figure out what it is doing. Maybe you could give a rough outline of
>>what it is supposed to do. Especially, focus on the jack_close() call,
>>because I think there may be a problem there. You seem to the close
>>when *any* jack object is destroyed (as opposed to the *last* object).
>>This could be the source of your troubles since the $if_jack_active
>>object is destroyed as soon as conky_parse terminates. (at least I
>>think it is, feel free to verify).
>
>Ah yes, that makes a lot of sense, I hadn't really delved in deep to
>look at what is happening with the creation of conky objects. I'll
>use a counter incremented on calls to jack_init and decremented
>in jack_close, and only call jack_client_close when the counter reaches
>zero (unless conky already has a mechanism for this?).
>
>
>>
>>Also I find that semaphore thingy quite strange. What exactly are you
>>trying to achieve there?
>
>My grasp of multi-threading is a bit weak, so that's just something
>I've taken from another project[1]. jack_shutdown_cb() is called by
>JACK[2] never by conky so the semaphore is there to cause this
>communication between different process threads to hopefully happen in
>a thread safe manner!
>
>
>HTH,
>James.
>
>[1]
>https://github.com/danmbox/jack-file/blob/master/csrc/file2jack.c#L634
>
>[2]
>http://jackaudio.org/files/docs/html/group__ClientCallbacks.html#ga417b907ee02efbe00f5e9a2f4d202599
>

I'll explain a little bit about JACK here - I don't know how much you
know about it so bear with me.

First thing, we can't assume JACK will be running or not running or stay
in either of those states (probably similar to mpd/xmms etc).

The on_shutdown callback might be called when the user stops the JACK
server - which is certainly not uncommon. Or sometimes if the client is
taking too much load and not keeping up with real-time requirements,
JACK will 'zombify' the client and kick it out of the processing
graph (ie heavy real-time fx processing or huge multi-track recordings
may cause such a thing). There are a few other reasons too.

Since many of the functions we're using to obtain information
about the JACK server require registration as a client we need to
know when we no longer are a JACK client otherwise we'll get
the dreaded sig-segv - which considering conky's main task is NOT as a
JACK client, would be poor going.

I've just made a further commit to my conky fork, have added a counter
to prevent the action I previously described and it works as we
suspected. Have left a few printf's in place so you can see what's
going on (if you run it and have jack?)..

this might help:


TEXT
#-------------------------------------------------
${if_jack_active}
${color 00cdcd}jack cpu load:		${goto 100}${color
00af00}${jack_cpu_load}% ${color 00cdcd}jack buffer size:	${goto
100}${color 00af00}${jack_buffer_size} ${color 00cdcd}jack sample
rate:	${goto 100}${color 00af00}${jack_sample_rate} ${color
cd0000}jack xruns:			${goto 100}${color
af0000}${jack_xruns}${else} ${color 00cdcd}jack cpu
load:		${goto 100}${color af0000}-- ${color 00cdcd}jack
buffer size:	${goto 100}${color af0000}-- ${color 00cdcd}jack
sample rate:	${goto 100}${color af0000}-- ${color cd0000}jack
xruns:			${goto 100}${color af0000}0${endif}
${if_jack_rolling}${color 00ff00}Rolling${else}${color
ff0000}Stopped${endif} ${if_jack_bbt}
${jack_beat_type}/${jack_beats_per_bar} ${jack_bpm}bpm
BBT:${jack_bar}:${jack_beat}:${jack_tick}${endif} ${jack_frame}
${jack_hour}:${jack_min}:${jack_sec}



cheers,
james.

On 30/01/13 Pavel Labath <pa...@ce...> wrote:
>On 30/01/13 14:34, James Morris wrote:
>> On 30/01/13 James Morris <ja...@jw...> wrote:
>>> Hi,
>>>
>>> Just sent a pull request on github for my latest changes.
>>>
>>> Aside from the omission of 'experimental' time data, and server
>>> control (stop/start/etc), pretty much all data is available.
>>>
>>> Added documentation and fixed problems with conkyrc reload.
>>>
>>> cheers,
>>> james.
>> 
>> 
>> hmmm, just found an odd problem with code like this within lua:
>> 
>> 	if conky_parse("${if_jack_active}1${else}0${endif}") == "1"
>> then print("jack active")
>> 	else
>> 		print("jack not active")
>> 	end
>> 
>> init_jack is called on every update but my flag to prevent
>> re-registering of the jack client seems to be ignored when called
>> from lua.
>> 
>> think this is what stumped me the other week giving me cold feet
>> from the prospect it might be a threads issue... is lua processing
>> done in a different thread or something? or is my logic for
>> preventing re-registration of conky as a jack client flawed????
>> 
>> james.
>> 
>
>Hi,
>
>I've tried to wrap my head around your code, but I cannot seem to
>figure out what it is doing. Maybe you could give a rough outline of
>what it is supposed to do. Especially, focus on the jack_close() call,
>because I think there may be a problem there. You seem to the close
>when *any* jack object is destroyed (as opposed to the *last* object).
>This could be the source of your troubles since the $if_jack_active
>object is destroyed as soon as conky_parse terminates. (at least I
>think it is, feel free to verify).

Ah yes, that makes a lot of sense, I hadn't really delved in deep to
look at what is happening with the creation of conky objects. I'll
use a counter incremented on calls to jack_init and decremented
in jack_close, and only call jack_client_close when the counter reaches
zero (unless conky already has a mechanism for this?).


>
>Also I find that semaphore thingy quite strange. What exactly are you
>trying to achieve there?

My grasp of multi-threading is a bit weak, so that's just something
I've taken from another project[1]. jack_shutdown_cb() is called by
JACK[2] never by conky so the semaphore is there to cause this
communication between different process threads to hopefully happen in
a thread safe manner!


HTH,
James.

[1]
https://github.com/danmbox/jack-file/blob/master/csrc/file2jack.c#L634

[2]
http://jackaudio.org/files/docs/html/group__ClientCallbacks.html#ga417b907ee02efbe00f5e9a2f4d202599



>
>cheers,
>pl
>
>



-- 
http://jwm-art.net/
image/audio/text/code/

On 30/01/13 14:34, James Morris wrote:
> On 30/01/13 James Morris <ja...@jw...> wrote:
>> Hi,
>>
>> Just sent a pull request on github for my latest changes.
>>
>> Aside from the omission of 'experimental' time data, and server
>> control (stop/start/etc), pretty much all data is available.
>>
>> Added documentation and fixed problems with conkyrc reload.
>>
>> cheers,
>> james.
> 
> 
> hmmm, just found an odd problem with code like this within lua:
> 
> 	if conky_parse("${if_jack_active}1${else}0${endif}") == "1" then
> 		print("jack active")
> 	else
> 		print("jack not active")
> 	end
> 
> init_jack is called on every update but my flag to prevent
> re-registering of the jack client seems to be ignored when called from
> lua.
> 
> think this is what stumped me the other week giving me cold feet
> from the prospect it might be a threads issue... is lua processing done
> in a different thread or something? or is my logic for preventing
> re-registration of conky as a jack client flawed????
> 
> james.
> 

Hi,

I've tried to wrap my head around your code, but I cannot seem to figure
out what it is doing. Maybe you could give a rough outline of what it is
supposed to do. Especially, focus on the jack_close() call, because I
think there may be a problem there. You seem to the close when *any*
jack object is destroyed (as opposed to the *last* object). This could
be the source of your troubles since the $if_jack_active object is
destroyed as soon as conky_parse terminates. (at least I think it is,
feel free to verify).

Also I find that semaphore thingy quite strange. What exactly are you
trying to achieve there?

cheers,
pl

On 30/01/13 James Morris <ja...@jw...> wrote:
>Hi,
>
>Just sent a pull request on github for my latest changes.
>
>Aside from the omission of 'experimental' time data, and server
>control (stop/start/etc), pretty much all data is available.
>
>Added documentation and fixed problems with conkyrc reload.
>
>cheers,
>james.


hmmm, just found an odd problem with code like this within lua:

	if conky_parse("${if_jack_active}1${else}0${endif}") == "1" then
		print("jack active")
	else
		print("jack not active")
	end

init_jack is called on every update but my flag to prevent
re-registering of the jack client seems to be ignored when called from
lua.

think this is what stumped me the other week giving me cold feet
from the prospect it might be a threads issue... is lua processing done
in a different thread or something? or is my logic for preventing
re-registration of conky as a jack client flawed????

james.



>
>------------------------------------------------------------------------------
>Everyone hates slow websites. So do we.
>Make your web apps faster with AppDynamics
>Download AppDynamics Lite for free today:
>http://p.sf.net/sfu/appdyn_d2d_jan
>_______________________________________________
>Conky-development mailing list
>Con...@li...
>https://lists.sourceforge.net/lists/listinfo/conky-development



-- 
http://jwm-art.net/
image/audio/text/code/

Hi,

Just sent a pull request on github for my latest changes.

Aside from the omission of 'experimental' time data, and server
control (stop/start/etc), pretty much all data is available.

Added documentation and fixed problems with conkyrc reload.

cheers,
james.

Hi,

I've just pushed a couple more commits to the 1.9.1 branch of my fork of
Conky. I've put it together fairly quickly so want to give it the
chance to get tested by others before making pull requests.

See: https://github.com/jwm-art-net/conky.git

Don't forget, checkout 1.9.1, ./configure --enable-jack etc.

These more than double the variables I'd previously made for JACK
within Conky. In particular I want to know if the way I've dealt with
time is acceptable - separate variables for hours, minutes, seconds,
etc, as well as the code itself in jack.c (decided to save a couple of
int's by using bit-twiddling).

Cheers,
James.

On 15/01/13 Pavel Labath <pa...@ce...> wrote:
>On 15/01/13 14:10, James Morris wrote:
>> On 15/01/13 James Morris <ja...@jw...> wrote:
>>>
>>> Eventually figured out the only time I have seen the
>>>> bargraph_small.lua
>>> script working with the master branch is when reading an old config
>>> file. Reading a new config file seems to ignore the lua scripts.
>> 
>> 
>> Sorry for the noise. Oblivious to the fact my hand-written conversion
>> was syntactically incorrect. Using the convert script included, lo
>> and behold, it all works.
>> 
>> James.
>> 
>> 
>
>Hi,
>
>thanks for taking interest in conky. I have merged your pull requests.
>If you have any more, just let me know.
>
>Wrt master branch, I just wanted to say that the syntax of the config
>file is not definite. It's just some (semi-functional) intermediate
>phase that got merged into master. I want to go full lua eventually
>(including the TEXT section), but I don't have a lot of time to do that
>lately, so it's been kinda stuck there for a while. I've been doing
>some work on that in the lua-config branch (feel free to take a look),
>but it's far from complete. This intermediateness is the reason why
>i'm not that worried about supporting every lua script out there, but
>hey, it's great you got it working. If you need any further help, just
>write, and I'll try to answer.
>
>Happy hacking,
>pl
>

Hi,

Thanks for the comments.

Forged ahead and got the basics of the JACK Audio Connection Kit data
in the 1.9.1 branch working. I've not made any pull request yet, bit
early, but here's a link to the commit on my fork if you want to look:

https://github.com/jwm-art-net/conky/commit/501bdc03e8e6b141073c0e56f07b67cd6fd69645

Any comments appreciated.


I had a quick look at lua-config last night but the build failed due to
not finding O_CLOEXEC in fcntl.h. It's definied in bits/fcntl-linux.h
(via bits/fcntl.h). O_CLOEXEC isn't the only symbol c++wrap needs from
fcntl.

Cheers,
James.

On 15/01/13 14:10, James Morris wrote:
> On 15/01/13 James Morris <ja...@jw...> wrote:
>>
>> Eventually figured out the only time I have seen the
>>> bargraph_small.lua
>> script working with the master branch is when reading an old config
>> file. Reading a new config file seems to ignore the lua scripts.
> 
> 
> Sorry for the noise. Oblivious to the fact my hand-written conversion
> was syntactically incorrect. Using the convert script included, lo and
> behold, it all works.
> 
> James.
> 
> 

Hi,

thanks for taking interest in conky. I have merged your pull requests.
If you have any more, just let me know.

Wrt master branch, I just wanted to say that the syntax of the config
file is not definite. It's just some (semi-functional) intermediate
phase that got merged into master. I want to go full lua eventually
(including the TEXT section), but I don't have a lot of time to do that
lately, so it's been kinda stuck there for a while. I've been doing some
work on that in the lua-config branch (feel free to take a look), but
it's far from complete. This intermediateness is the reason why i'm not
that worried about supporting every lua script out there, but hey, it's
great you got it working. If you need any further help, just write, and
I'll try to answer.

Happy hacking,
pl

On 15/01/13 James Morris <ja...@jw...> wrote:
>
>Eventually figured out the only time I have seen the
>>bargraph_small.lua
>script working with the master branch is when reading an old config
>file. Reading a new config file seems to ignore the lua scripts.


Sorry for the noise. Oblivious to the fact my hand-written conversion
was syntactically incorrect. Using the convert script included, lo and
behold, it all works.

James.

On 15/01/13 James Morris <ja...@jw...> wrote:

(still talking about the master branch on github)
>Also worth a mention is the lua/cairo scripting isn't quite as broken
>as I previously thought having since witnessed the bargraph_small.lua
>script working via the master branch. Unfortunately it was nested
>amongst a screenfull of window damage and garbage that no doubt would
>have glitch-art aficionados applauding.


The glitch garbage was caused by not having the x-double-buffer
extension (XDBE) enabled when building the master branch but trying to
use double buffering. Without XDBE, trying to use double-buffering and
own_window=true resulted in an X Error, BadMatch, X_CopyArea
(something like that).

Enabling XDBE gets rid of the screenful of glitch-art (ie when
((double_buffer=true && own_window=false) || (double_buffer=false &&
own_window=true))

A console message could help in these kinds of instances.

Eventually figured out the only time I have seen the bargraph_small.lua
script working with the master branch is when reading an old config
file. Reading a new config file seems to ignore the lua scripts.

James.

On 14/01/13 James Morris <ja...@jw...> wrote:

>I went on IRC yesterday with another problem:
>
>conky: llua_load: error loading module 'cairo' from file
>'/usr/local/lib/conky/libcairo.so': /usr/local/lib/conky/libcairo.so:
>undefined symbol: cairo_copy_path_flat
>
>Which I suspected to be a linker problem and thought it may have arisen
>due to cmake not honouring the request to link a target library named
>cairo (Conky's libcairo) with a library named cairo (Cairo's libcairo).
>
>I believe when I renamed Conky's cairo (in the CMakeLists.txt),
>this problem disappeared but I don't know my way around enough to deal
>with the consequences of that (and can't be bothered to verify it again
>right now).
>
>Looking in the master branch (w/o the libcairo name change) the linker
>command is shown (without an explicit -lcairo) in
>lua/CMakeFiles/cairo.dir/relink.txt:
>/usr/bin/cc  -fPIC -O3 -ggdb   -shared -Wl,-soname,libcairo.so -o
>CMakeFiles/CMakeRelink.dir/libcairo.so
>CMakeFiles/cairo.dir/libcairo.c.o -lX11 -lXext -llua5.1 -lm
>-Wl,-Bstatic -ltolua++ -Wl,-Bdynamic

Found a fix for this linkage error now. It is down to the target name
as referred to within the lua/CMakeLists.txt. What I have done is
change the target name from cairo to conky-cairo. Then, using
SET_TARGET_PROPERTIES, the OUTPUT_NAME can be set back to
cairo again so that libcairo.so is created rather than libconky-cairo.
Voila, Conky's libcairo now links properly.

This doesn't solve any of the deeper issues of course, but is a step
forward.

Also worth a mention is the lua/cairo scripting isn't quite as broken
as I previously thought having since witnessed the bargraph_small.lua
script working via the master branch. Unfortunately it was nested
amongst a screenfull of window damage and garbage that no doubt would
have glitch-art aficionados applauding.

james.

I can confirm your compilation issues except the Lua version problem on
Debian (Testing/Unstable).
I have never been able to get the master branch to build a functional
conky.
The last time I tried the build worked (after a problem in the build
system was fixed) but the resulting program was non-functional.

I wrote up some instructions on how to build the branches that are still
in C and have the option to build with autotools instead of cmake on
Debian.
You can find them here.
http://crunchbang.org/forums/viewtopic.php?pid=235443%23p235443

I also had the problem with conky being unable to load its Lua bindings.
This is seems to be because conky builds its own custom Lua modules to
bind to cairo and imlib2 and is hardcoded to look in one place for them.
The problem is that the build scripts don't install theses modules so
conky can't find them.
This is the workaround for that that I found an the Internet somewhere.

cd lua
make clean
make
sudo make install

I also had problems with the install script expecting there to be a man
page file but the build script not making it so the install fails when
it tries to install the man page.
I have to build the man page manually like this

cd ../doc
docbook2x-man docs.xml

before I run "make install" to work around that.

Hi,

I've been trying to dig around in the conky source code but I don't
really know which of the branches I should really be looking at.

My original motivation was the idea of creating conky
objects/modules for displaying information about the Jack Audio
Connection Kit.

First off, attempts at building the master branch seemed broken. I then
moved to the 1.9.1 branch which also failed. Part of the problem in
both cases was my system has lua 5.2 and 5.1 simultaneously installed,
with 'lua' pointing to 5.2 (which has deprecated many of the symbols
used by conky).

I've made two pull requests on github which fix these (for Arch Linux
at least) by forcing usage of lua5.1 but haven't got round to testing on
other systems yet (the only other immediately available system to me for
testing on is a debian stable system).

I went on IRC yesterday with another problem:

conky: llua_load: error loading module 'cairo' from file
'/usr/local/lib/conky/libcairo.so': /usr/local/lib/conky/libcairo.so:
undefined symbol: cairo_copy_path_flat

Which I suspected to be a linker problem and thought it may have arisen
due to cmake not honouring the request to link a target library named
cairo (Conky's libcairo) with a library named cairo (Cairo's libcairo).

I believe when I renamed Conky's cairo (in the CMakeLists.txt),
this problem disappeared but I don't know my way around enough to deal
with the consequences of that (and can't be bothered to verify it again
right now).

Looking in the master branch (w/o the libcairo name change) the linker
command is shown (without an explicit -lcairo) in
lua/CMakeFiles/cairo.dir/relink.txt:
/usr/bin/cc  -fPIC -O3 -ggdb   -shared -Wl,-soname,libcairo.so -o
CMakeFiles/CMakeRelink.dir/libcairo.so
CMakeFiles/cairo.dir/libcairo.c.o -lX11 -lXext -llua5.1 -lm
-Wl,-Bstatic -ltolua++ -Wl,-Bdynamic

Looking at the 1.9.1 branch, cairo is explicitly linked in:
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libcairo_la-libcairo.o
-lcairo -lX11 -lXext -llua5.1 -lm -ltolua++    -Wl,-soname
-Wl,libcairo.so.0 -o .libs/libcairo.so.0.0.0

Back in the master branch, if I manually link libcairo.so with the
with the missing -lcairo (ie between -lm and -Wl) and copy it to the
install location, the undefined symbol message disappears.

However, AFAICT, lua isn't working at all. The bargraph_small.lua script
by wlourf does nothing*. Neither does something simple such as:

function conky_test()
    print "Hello!"
end

Nothing is printed on the console.

I've never looked into lua before now, so am a bit lost as far as
debugging goes. I don't know why cmake isn't linking Cairo's cairo into
Conky's cairo. I've a slight doubt that it should, but can't grep any
evidence of dlopen in use anywhere.

Going back to my original motivation to show JACK statistics I would
probably find it easier to code this into the 1.9.1 branch as I have
more familiarity with C than C++.

Appreciate any confirmation of this. 

Thanks.
James.



-- 
http://jwm-art.net/
image/audio/text/code/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


FYI, I've imported conky to our official package tree, the patches are now 
available here: 
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/conky/patches/?only_with_tag=MAIN

you can grab them using the following:

$ cvs -d an...@an...:/cvsroot co pkgsrc/sysutils/conky

I'll remove pkgsrc-wip conky (our package sandbox, previous link I sent) 
anytime soon.

Cheers,

- -------------------------------------------
Emile "iMil" Heitor .°. <im...@ho...>                               _
                         http://gcu-squad.org        ASCII ribbon campaign ( )
                                                      - against HTML email  X
                                                                  & vCards / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (NetBSD)

iD8DBQFPs2hCFG3BlGWyzUIRAuiSAJ4zWb6pElmpdsToEK2SHcgpyCJbYQCcCb+6
hSaNTe2zjXpiJEp3z62XzQM=
=Jv2v
-----END PGP SIGNATURE-----