lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] plugin_wifi ?

[Martin H. <ma...@he...>]

Hi again,

> - another way is using ioctl : in fact there's no direct ioctl for
> wireless extensions, the stats are merged with "generic" stats (see
> include/linux/netdevice.h and include/net/iw_handler.h), works with all
> kernels (the new API is from 2002), but it handles too the 'normal' eth
> devices, so why not calling this plugin_net and delete plugin_netdev ?
Second thoughts - after looking at the kernel stuff (the other end of 
the IOCTL calls), I'd even say it's smart to keep those separated.
So far, I've been unable to locate _any_ location in the kernel, where 
one can get the the same device-stats (rx_bytes, tx_bytes and so on) via 
ioctl calls as one gets via parsing the output of /proc/net/dev.

If we keep things separate, it should keep things nice and simple:
* plugin_net_dev for printing traffic stats - afterall, displaying bytes 
sent/received is pretty much independant of the actual implementation of 
the device)
* plugin_wireless (or whatever name we decide to use), for extra info 
(like channel, operation mode, sensitivity, transmit power, link 
quality, signal level, noise level and so on). All of those are very 
"wifi-specific", so keeping this separate should help keep things 
compact, once we go to dynamic loading of plugins.


If, on the other hand, you've found a way to get the same info via ioctl 
calls as one can get from /proc/net/dev, please do tell me - I'd love to 
know a way to get around having to parse that potentially large string 
(one of my test boxes has 10 different interfaces in /proc/net/dev - not 
only physical ones, but also logical ones, for VPNs and stuff like that).

Martin

Re: [Lcd4linux-devel] plugin_wifi ?

[Martin H. <ma...@he...>]

Hi Xavier,

> - the first is parsing /proc/net/wireless (which exists for both 2.4 and
> 2.6) as /proc/net/dev, there are all the informations (unlike
> /proc/net/dev which shows only a few info).
This is an option - especially if one needs a plugin quickly (since it 
should be the easiest to implement).

> - another way is using ioctl : in fact there's no direct ioctl for
> wireless extensions, the stats are merged with "generic" stats (see
> include/linux/netdevice.h and include/net/iw_handler.h), works with all
> kernels (the new API is from 2002), but it handles too the 'normal' eth
> devices, so why not calling this plugin_net and delete plugin_netdev ?
Well, I'd favour this solution (using ioctl calls), but I would't rush 
into replacing something that works (plugin_netdev).
At first glance, trying to handle wireless devices (which supply 
additional data, which in turn is why there's need for a wifi-plugin to 
begin with) together with traditional network devices could make the 
code pretty ugly fast.

Lets get the wireless stuff taken care of first, and then see how we can 
merge traditional network devices and wireless devices.

> - the last way which won't please to Martin : all statistics ('normal' +
> wireless extensions) are exported in
> /sys/class/net/$interface_name/statistics, so we can access them
> easilly, just as plugin_i2c_sensors does ! But as you may guess, sysfs
> is only on 2.6.
Which IMHO pretty much rules out that option. I guess it will be a while 
until the majority of people will be using 2.6 (to my knowledge, there's 
only one distro that comes with 2.6 at this moment) - and even when 2.6 
becomes more common - I fail to see why a userspace app like lcd4linux 
would have to rely on the latest available kernel. If you feel like it, 
make it a configure option, if you want to get really fancy, detect 
which parsing routine to use at run-time, just like Michael does for the 
busy-waiting routine (or go ahead and code the wifi plugin for 2.6, and 
I'll code a 2.4 plugin for the rest of us).

> Now my point of view: the last two ways overpower plugin_netdev which
> can be removed then, and the plugin would be called plugin_net instead
> of plugin_wifi. But then, which one to use ? Using sysfs would be very
> easy and I can write the plugin in about 2hours from plugin_i2c_sensors,
If you do, please don't make that plugin "scream" like the i2c plugin, 
if it doesn't find its "/sys/whatever" directory. It is slightly 
annoying to have a plugin (that's not even referenced in the config) 
give errors on the command line, even when everything in the config is 
perfectly right.

> but some people will complain about their old, deprecated, outdated,
> superseeded, ..., 2.4 kernel not being supported :/ 
Indeed - not to speak of the people using the even older, even more 
deprecated, even more outdated, even more superseeded 2.2 (or dare I say 
2.0? I don't know if lcd4linux will run on a 2.0 kernel, but I'm 
guessing it should at least run on 2.2). What it comes down to for me is 
this: I don't see why some userspace app should dictate which kernel a 
person uses - especially not if there are perfectly fine ways of getting 
the same result without adding a dependency to kernel 2.6. But that's 
just me.

> We may in that case
> keep plugin_netdev and write rapidly a plugin_net_wireless which parses
> /proc/net/wireless (easilly writen too) so they can delay once more the
> migration to the best kernel ever released ( until 2.8 is out :D )
I think everybody on this list has understood by now that you are a big 
fan of 2.6 - so, if you want to write a "2.6 only" plugin, feel free to 
do so. But be assured - you won't make _me_ change to 2.6 any time soon 
;-) I may set up a test box some day to see if all the apps I need still 
work under 2.6, but for now, I'm happy to have a system that simply 
works (giving me time to work on other things - lcd4linux, for example - 
instead of playing with my linux installation).

> The best solution would be ioctl, but I don't know how to do this, and I
> don't know if it's worth the price to do this manner. If you know ioctl
> and wants to dig this way, just raise your hand :)
<Raises hand>
I'll take care of it. I can't say when (I unfortunately had to get some 
"real" work done this weekend (as in, "stuff one gets paid for"), but 
I'll try to put something together by next weekend.
</Raises hand>

Martin

Re: [Lcd4linux-devel] new website desing ?

[Xavier V. <xav...@fr...>]

Hello list !

Here's a tar.bz2 of a static xhtml/css page which is a desing test for
the new website. All the explanations are writen in the page itself.

Mail comments and impressions here please.

Bye !
-- 
Xavier VELLO <xav...@fr...>

PS: this has been tested only on gecko-based browsers (mozilla 1.4 and epiphany), but it should
work with konqueror and others too.

[Lcd4linux-devel] plugin_wifi ?

[Xavier V. <xav...@fr...>]

Hello list, especially Martin and Michael.

Let's continue our dicussion about plugin_wifi :
I see three solutions to the claim :

- the first is parsing /proc/net/wireless (which exists for both 2.4 and
2.6) as /proc/net/dev, there are all the informations (unlike
/proc/net/dev which shows only a few info).

- another way is using ioctl : in fact there's no direct ioctl for
wireless extensions, the stats are merged with "generic" stats (see
include/linux/netdevice.h and include/net/iw_handler.h), works with all
kernels (the new API is from 2002), but it handles too the 'normal' eth
devices, so why not calling this plugin_net and delete plugin_netdev ?

- the last way which won't please to Martin : all statistics ('normal' +
wireless extensions) are exported in
/sys/class/net/$interface_name/statistics, so we can access them
easilly, just as plugin_i2c_sensors does ! But as you may guess, sysfs
is only on 2.6.

Now my point of view: the last two ways overpower plugin_netdev which
can be removed then, and the plugin would be called plugin_net instead
of plugin_wifi. But then, which one to use ? Using sysfs would be very
easy and I can write the plugin in about 2hours from plugin_i2c_sensors,
but some people will complain about their old, deprecated, outdated,
superseeded, ..., 2.4 kernel not being supported :/ We may in that case
keep plugin_netdev and write rapidly a plugin_net_wireless which parses
/proc/net/wireless (easilly writen too) so they can delay once more the
migration to the best kernel ever released ( until 2.8 is out :D )

The best solution would be ioctl, but I don't know how to do this, and I
don't know if it's worth the price to do this manner. If you know ioctl
and wants to dig this way, just raise your hand :)

Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Martin H. <ma...@he...>]

Hi Xavier,

>>My suggestion (and that's the way I understood Michael as well) is to 
>>use a "worker process/thread" for each plugin that will be slow/may 
>>block. Memory consumption is not so much an issue, since most of it will 
>>be marked as "shared" anyway, so memory usage on the box will only 
>>increase marginally.
> 
> Okay, I was misinformed about fork. Let's continue this way.
> But another question : for example eval needs the mail('unread') value,
> so calls a (hypothetical) mail() function in plugin_mail, which forks to
> retreive POP summary, and it takes, for example, 5 seconds, what does
> the eval do within this time ? I don't know what Michael wants on this
> issue.
I guess Michael has already answered that one. If eval waited for the 
fork to complete (and deliver the data), we'd still be doing things 
synchronously, and thus would have gained nothing.

To get around that problem with the first call failing - I guess we 
could get fancy and supply some kind of "callback" (which would get 
called when the data is available) - but to me it sounds like that would 
be overkill, considering we're only talking about the first call to that 
function that causes problems.

>>A syscall? Care to explain? All I know so far is that the wireless 
>>extensions API works via IOCTL calls - I never heard/read of syscalls 
>>for that in the past (maybe this is simply about a different definition 
>>of "syscall" - to me, a "syscall" is a function exported by the kernel - 
>>whereas an IOCTL call is a specific syscall, that takes specific 
>>parameters (and those parameters tell it what to do)).
> 
> I don't really know what is the difference, I've not been hacking IOCTL
>  since this week :), but read linux-2.6.4/include/net/iw_handler.h,
>  there are a bunch of explanations there for the new API.
Well, please don't use _too_ new features, since that would mean people 
still running the 2.4 kernel will be left out. I would prefer to stick 
to the API defined here
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
to avoid compatibility problems (I don't know - maybe that's exactly 
what's made its way into 2.6 - I haven't run 2.6 so far, and from the 
look of things, it may still be a while until I will - not because I 
think 2.6 is bad, just because I don't have the time to mess with my 
system just for the heck of it).

> If it's possible, I would prefer to call this [IOCTL|syscall] instead of
> parsing /proc/net/wireless, as it's funnier and more educative for me.
Absolutely - besides, it should be much more efficient and less error 
prone. The only drawback is that it will hit us if the API changes 
(which is unlikely though, since the API seems to be pretty stable).

>>So, you _are_ working on that (or did you just add it to your ToDo 
>>list)? Don't get me wrong - I just want to make sure we don't duplicate 
>>work (and still get a working wifi plugin in a timely manner). I've 
>>added plenty of things onto my ToDo list in the past (which I never 
>>completed), so I want to make sure :-)
> 
> I'll write this, but you may help me if you know [IOCTL|syscall] well,
> as I don't know either how to do :)
Sure, just let me know if you need help. Using IOCTL is pretty simple - 
it's all about finding which parameters to use (which one usually needs 
to pick from the source of the driver one is calling into) - just have a 
look at drv_generic_parport.c in lcd4linux to get an idea how it's done 
(really, there's not much to it). The only thing one needs to be careful 
about is to provide the right kind of pointer for the 3rd parameter - if 
the driver expects a pointer to an int, and you supply a pointer to a 
char, strange things will happen.

> Reading plugin_dvb.c, IOCTL are special adresses in a /dev node, while,
> as far as I understand wireless extensions have merged in
> linux/include/linux/netdevice.h, and "INET is implemented using the BSD
> Socket interface as the means of communication with the user level"
> Help ?!?!
Well, IOCTLs are done on a filehandle (and usually on the file-handle of 
a file in the /dev/ directory). That's the most common. The wireless 
extensions apparently require IOCTL calls to a socket - which apparently 
works just as well.

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.Extensions.html

(especially the section 5.2 IOCTL) has some info on how that works.

If I were writing the plugin, I'd probably start out with going through 
the source-code of the wireless tools (which obviously use the wireless 
extensions API themselves), to get a feel for how things work.

I hope that helps.

Martin

-- 
You think that's tough?  Try herding cats!

[Lcd4linux-devel] Threads

[Michael R. <re...@eu...>]

Hi Xavier, Hi List,

> Okay, I was misinformed about fork. Let's continue this way.
I already started with a "simple threading" framework (nothing in CVS by 
now)

> But another question : for example eval needs the mail('unread') value,
> so calls a (hypothetical) mail() function in plugin_mail, which forks to
> retreive POP summary, and it takes, for example, 5 seconds, what does
> the eval do within this time ? I don't know what Michael wants on this
> issue.

It's simple: The first call to mail::unread() triggers the fork, and 
returns nothing (this is a drawback: oin the first call you'll never get 
a senseful result). From now on, the 2nd thread regularly polls the 
mailbox (at a configurable interval from the config file), ans stores 
the result in a special shared memory area. The main thread from 
mail::unread() does nothing but reading this shared memory area and 
returns the corresponding results. So the main thread is very fast and 
does never block.

The shared memory area itself will be protected by a mutex, to ensure 
that it's not written to by the poll thread while being read from the 
mail thread.

The best place for such a "shared memory parameter passing structure" 
would be our well-loved hash. But I'm not shure if this is possible...

I am starting this async stuff with the exec() plugin, because its 
simpler than POP polling, so I can focus on the threading framework. 
Exec's really need an async model, too, because you never can tell how 
long the exec'ed prcess will take today.


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Xavier V. <xav...@fr...>]

Hello Mirtin, hi list

> [...]
> My suggestion (and that's the way I understood Michael as well) is to 
> use a "worker process/thread" for each plugin that will be slow/may 
> block. Memory consumption is not so much an issue, since most of it will 
> be marked as "shared" anyway, so memory usage on the box will only 
> increase marginally.
Okay, I was misinformed about fork. Let's continue this way.
But another question : for example eval needs the mail('unread') value,
so calls a (hypothetical) mail() function in plugin_mail, which forks to
retreive POP summary, and it takes, for example, 5 seconds, what does
the eval do within this time ? I don't know what Michael wants on this
issue.

> A syscall? Care to explain? All I know so far is that the wireless 
> extensions API works via IOCTL calls - I never heard/read of syscalls 
> for that in the past (maybe this is simply about a different definition 
> of "syscall" - to me, a "syscall" is a function exported by the kernel - 
> whereas an IOCTL call is a specific syscall, that takes specific 
> parameters (and those parameters tell it what to do)).
I don't really know what is the difference, I've not been hacking IOCTL
 since this week :), but read linux-2.6.4/include/net/iw_handler.h,
 there are a bunch of explanations there for the new API.
If it's possible, I would prefer to call this [IOCTL|syscall] instead of
parsing /proc/net/wireless, as it's funnier and more educative for me.

> So, you _are_ working on that (or did you just add it to your ToDo 
> list)? Don't get me wrong - I just want to make sure we don't duplicate 
> work (and still get a working wifi plugin in a timely manner). I've 
> added plenty of things onto my ToDo list in the past (which I never 
> completed), so I want to make sure :-)
I'll write this, but you may help me if you know [IOCTL|syscall] well,
as I don't know either how to do :)
Reading plugin_dvb.c, IOCTL are special adresses in a /dev node, while,
as far as I understand wireless extensions have merged in
linux/include/linux/netdevice.h, and "INET is implemented using the BSD
Socket interface as the means of communication with the user level"
Help ?!?!

Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Martin H. <ma...@he...>]

Hi Xavier,

>>- lcd4linux will stay pure C (as the linux kernel does)
>>- lcd4linux will not use any threading library, the places where 
>>asynchronous execution is necessary are rare and will be solved using 
>>traditional fork() and shmem.
> 
> In fact to aswer to Martin, C++ threads are less memory-wasting than
>   the C fork(), as fork copy the whole process, with its variable and
>  others.
I'm very well aware of the difference between multi-threading and 
multi-processing. But IMHO your assumption is wrong, unless Linux 
nowadays works completely different from what I've learned in the past. 
Unless you change a variable, fork will reserve, but not actually use 
any of that address space. Besides, by "memory footprint" I was actually 
more referring to the almost 3MB large libstdc++.so that comes with 
using c++. I couldn't really care less if there's another 500k process 
running (at runtime) - but adding 3 MB in libs (which need to be saved 
on the install medium - which _may_ be a floppy, for my target 
plattform) surely is an issue for me. Especially so, if it's done so 
without a huge benefit.

> I don't know what you think about it, but maybe we can fork very early
> in 3 threads: main, plugins, and soon input to make all these work
> asyncronously and solve many problems we'll encounter with input. But
> this will surely lead to problems with shared variables and other.
> 
> Do as you want Michael, but IMHO slitting into 3 (by now 2) threads
> would be "proper". But we'll be able to troll about this after 0.10.0 is
> released. ;)
I don't think this is so much about "style", but rather about keeping 
the code maintainable. Forking and using IPC is something that works, 
and has been working for ages (even if it's not the most efficient way, 
and even if threads could do it better - lets be honest, we're not 
talking about megabytes of data per second being transferred between 
those processes). So, it's something that people are comfortable with, 
something that doesn't change anymore (unlike the threads API - or so I 
gather from the problems that came with the introduction of nptl), so it 
sounds like the way to go, as long as we don't have something that needs 
to move tons of data (IPC is relatively slow, afterall) and that isn't 
too time-critical.

I don't really see what we'll gain by limiting ourselves to 3 processes 
(or "threads" if you prefer those) - to me, every plugin should be able 
to create its own data-gatherer thread if it needs one.
If we go your route, it will only make the "plugins" process very 
complicated (since it needs to play scheduler), none of the functions 
may block, or other plugins will be blocked too, that kind of thing.

My suggestion (and that's the way I understood Michael as well) is to 
use a "worker process/thread" for each plugin that will be slow/may 
block. Memory consumption is not so much an issue, since most of it will 
be marked as "shared" anyway, so memory usage on the box will only 
increase marginally.

>>What about plugin_wifi? Martin will neeed it, IIRC.
> 
> I began to write it last week while recompiling a 2.6.3 kernel on a
> 133MHz notebook (so I had time to code :D ), it was a mere copy of
> plugin_netdev.c as the two files /proc/net/dev and /proc/net/wireless
> are similar, but I found a syscall to retreive the informations, 
A syscall? Care to explain? All I know so far is that the wireless 
extensions API works via IOCTL calls - I never heard/read of syscalls 
for that in the past (maybe this is simply about a different definition 
of "syscall" - to me, a "syscall" is a function exported by the kernel - 
whereas an IOCTL call is a specific syscall, that takes specific 
parameters (and those parameters tell it what to do)).

> I have to dig more about this function and write the
> plugin --> added to my ToDo :)
So, you _are_ working on that (or did you just add it to your ToDo 
list)? Don't get me wrong - I just want to make sure we don't duplicate 
work (and still get a working wifi plugin in a timely manner). I've 
added plenty of things onto my ToDo list in the past (which I never 
completed), so I want to make sure :-)

Martin

Re: [Lcd4linux-devel] cfg_get() > Segmentation fault

[Xavier V. <xav...@fr...>]

Hi Javi !

I suspect you're trowing a *char pointer to the connect function where
it expects a char. Maybe you can try :
char server;
&server=cfg_get(......

Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Xavier V. <xav...@fr...>]

Hello Michael, Martin and others

> - lcd4linux will stay pure C (as the linux kernel does)
> - lcd4linux will not use any threading library, the places where 
> asynchronous execution is necessary are rare and will be solved using 
> traditional fork() and shmem.
In fact to aswer to Martin, C++ threads are less memory-wasting than
  the C fork(), as fork copy the whole process, with its variable and
 others.

I don't know what you think about it, but maybe we can fork very early
in 3 threads: main, plugins, and soon input to make all these work
asyncronously and solve many problems we'll encounter with input. But
this will surely lead to problems with shared variables and other.

Do as you want Michael, but IMHO slitting into 3 (by now 2) threads
would be "proper". But we'll be able to troll about this after 0.10.0 is
released. ;)

> >>If you could make your Excel-Todo-Sheet up to date, this would be of 
> >>help here.
> > First, I don't use excel !!!!
> Sorry, I forgot that you already "ported" the Status list to ASCII :-)
Errr ... some people use free software like OOo instead of "crossover  
 office" ! See photo06.jpg of LinuxDay on the site, the last three  
 icons in the KDE panel : are these word, excel and powerpoint (at
 least I think) icons shortcuts to OOo components ? What can you argue
 for your defense ?

> What about plugin_wifi? Martin will neeed it, IIRC.
I began to write it last week while recompiling a 2.6.3 kernel on a
133MHz notebook (so I had time to code :D ), it was a mere copy of
plugin_netdev.c as the two files /proc/net/dev and /proc/net/wireless
are similar, but I found a syscall to retreive the informations, so I
dropped the source. I have to dig more about this function and write the
plugin --> added to my ToDo :)

Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Martin H. <ma...@he...>]

Hi Michael,

> - lcd4linux will stay pure C (as the linux kernel does)
> - lcd4linux will not use any threading library, the places where 
> asynchronous execution is necessary are rare and will be solved using 
> traditional fork() and shmem.
Glad to hear that.

> What about plugin_wifi? Martin will neeed it, IIRC.
Well, I had plans of writing it up myself today (but as always, 
something else got in the way). I'll give it a shot tomorrow, unless 
Xavier insists on doing it himself.

Martin

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Michael R. <re...@eu...>]

Hi Xavier,

> Another issue is the slow plugins (mysql, web, mail, ...), which we'll
> have to put in threads. A friend of mine recommended me to use C++ class
> Thread insted of fork(), which will increase a lot memory footprint.
> I fact, we won't have to port lcd4linux to C++, just  just introduce a
> little 'glue' to use these class. Should I go deeper in this way or do
> you _definitely_ want l4l to stay pure C ?

I fully agree with Martin here:

- lcd4linux will stay pure C (as the linux kernel does)
- lcd4linux will not use any threading library, the places where 
asynchronous execution is necessary are rare and will be solved using 
traditional fork() and shmem.

>>If you could make your Excel-Todo-Sheet up to date, this would be of 
>>help here.
> 
> First, I don't use excel !!!!
Sorry, I forgot that you already "ported" the Status list to ASCII :-)

> The status file is in plain text, I attached a patch to put it up to
> date (mysql and X11)

Fine, thanks!

What about plugin_wifi? Martin will neeed it, IIRC.


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Martin H. <ma...@he...>]

Hi Xavier,

> I know, but this will be quite complicated, so I'm beginning the search
> help for this.
> Another issue is the slow plugins (mysql, web, mail, ...), which we'll
> have to put in threads. A friend of mine recommended me to use C++ class
> Thread insted of fork(), which will increase a lot memory footprint.
> I fact, we won't have to port lcd4linux to C++, just  just introduce a
> little 'glue' to use these class. Should I go deeper in this way or do
> you _definitely_ want l4l to stay pure C ?
I obviously can't speak for Michael, but I surely hope he's going to 
keep it pure C - since my target platform doesn't even have the c++ libs 
installed (so, it would _hugely_ increase the memory footprint). 
Besides, I fail to see why one would need c++, just to be able to use 
plain threads. While I've never coded threads in c under linux (I have 
done so on other operating systems), I don't really see the huge benefit 
of using c++ (apart from the fact that it's slightly easier to use, but 
that probably would be lost in the glue-code).

I guess if we actually start using threads, things could get ugly 
quickly (with all the changes happening at the moment between different 
kernel versions at the moment - mainly nptl-related), so I must say I 
like Michael's approach of "old fashioned" fork and IPC (via shared-mem, 
sockets, pipes, whatever). It's surely not the most efficient way, but 
nobody's going to check the inbox every couple of miliseconds anyway.

Martin

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Xavier V. <xav...@fr...>]

Hello Michael !

> Ok. Just wait. I'll get you for this.
?!

> > First, I've 2 weeks of 'void' before the exams. I'm planning :
> > - searching people to help for dynamic so
> Fine, but this is 0.10.1 stuff. We should try to release 0.10.0 before
I know, but this will be quite complicated, so I'm beginning the search
help for this.
Another issue is the slow plugins (mysql, web, mail, ...), which we'll
have to put in threads. A friend of mine recommended me to use C++ class
Thread insted of fork(), which will increase a lot memory footprint.
I fact, we won't have to port lcd4linux to C++, just  just introduce a
little 'glue' to use these class. Should I go deeper in this way or do
you _definitely_ want l4l to stay pure C ?

> > - coding the test of the new website
> Fine.
I'm first working on how to include docbook-make docs (with CSS) and
 thinking about the desing.

> > - sleeping :)
> Why? What for? You are young, I suppose. So sleeping isn't necessary.
Yes, I'm young, but a having a lie-in is really good :)

> > Is there something more useful to code for lcd4linux ? I don't think I
> > can help for namespaces, maybe I could think about input ?
> If you could make your Excel-Todo-Sheet up to date, this would be of 
> help here.
First, I don't use excel !!!!
The status file is in plain text, I attached a patch to put it up to
date (mysql and X11)

Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] new website desing ?

[Michael R. <re...@eu...>]

Hi Xavier,

> Michael, did you receive the examples I sent you the 02/03 ? Do you like
> one ? Do you really want to keep the LCD style ?
I had a quick look. I don't like style2, the others look good to me. But 
I'm not a designer...

> IMHO, I don't like to go in a "nerd" way and always prefer simple and
> "sober" desing than web pages with 500KB of images for a menu. A friend
> told me to really go in LCD style, with an lcd patern in backgroud and
> really horrible things, I dislike that.

I think the answer should be somewhere in the middle. I too don't like a 
"nerd" style, but too "sober" would be bad, too.

I'd like to keep some of the LCD style. As for the size, these images 
are quite optimized, the main menu entries on the left side are about 
200 bytes each (bytes, not kB!)

I'm a bit biassed here because the original web layout was made by my 
girlfriend :-)


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Michael R. <re...@eu...>]

Hi Xavier,

>>Xavier, are you trying to undermine my authority? :-)
> 
> Yes :) 

Ok. Just wait. I'll get you for this.

> First, I've 2 weeks of 'void' before the exams. I'm planning :
> - searching people to help for dynamic so
Fine, but this is 0.10.1 stuff. We should try to release 0.10.0 before

> - coding the test of the new website
Fine.

> - sleeping :)
Why? What for? You are young, I suppose. So sleeping isn't necessary.

> Is there something more useful to code for lcd4linux ? I don't think I
> can help for namespaces, maybe I could think about input ?

If you could make your Excel-Todo-Sheet up to date, this would be of 
help here.


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [Lcd4linux-devel] cfg_get() > Segmentation fault

[Michael R. <re...@eu...>]

Hi Javi,

>>>The problem is wherever I use cfg_get() function I get "Segmentation
>>>fault" when running lcd4linux.
>>
>>Can you send me the code?
> 
> Upsss ;) I forgot it
> Just insert
>  char *get=cfg_get("MySQL","server","NOT FOUND");
> wherever in pluging_mysql.c

As I cannot test because I don't have MySQL installed here, I'd need the 
full code.

Normally if a library segfaults, it means that you passed wrong parameters.

> #1  0x08054ca3 in my_MySQLquery (result=0x806f060, server=0x8060d40, login=0x8060d40, pass=0x8060d40, database=0x8060d40, query=0x8060d40)
Strange: all pointers have the same address....

> #3  0x0804db29 in Eval (tree=0x806ef20, result=0xbffff010) at evaluator.c:1216
This pointer looks strange, too....

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [Lcd4linux-devel] new website desing ?

[Xavier V. <xav...@fr...>]

Hi list !

I'm coding a test for the new website, but I'm really stuck on the
webdesing and style part. In fact, I know I should keep the LCD style
for this site to keep in sync with the soft itself, but I'm not inspired
at all :/

Michael, did you receive the examples I sent you the 02/03 ? Do you like
one ? Do you really want to keep the LCD style ?

IMHO, I don't like to go in a "nerd" way and always prefer simple and
"sober" desing than web pages with 500KB of images for a menu. A friend
told me to really go in LCD style, with an lcd patern in backgroud and
really horrible things, I dislike that.

What do you all think about this issue ? Do you think having a "sober"
website would make lcd4linux loose less attractive ?
Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] cfg_get() > Segmentation fault

[Javi <ja...@gs...>]

Hi.

> > The problem is wherever I use cfg_get() function I get "Segmentation
> > fault" when running lcd4linux.
> Can you send me the code?
Upsss ;) I forgot it
Just insert
 char *get=cfg_get("MySQL","server","NOT FOUND");
wherever in pluging_mysql.c
 
> > Program received signal SIGSEGV, Segmentation fault. 0x08062fd9 in ??
> strange. Does "bt" or "u" work?

If it is inseted into my_MySQLquery(...) then:
# gdb --args lcd4linux -Fq
(gdb) run Starting program: /home/javi/proyectos/lcd4linux/lcd4linux -Fq

Program received signal SIGSEGV, Segmentation fault.
0x08062fd9 in ?? ()
(gdb) bt
#0  0x08062fd9 in ?? ()
#1  0x08054ca3 in my_MySQLquery (result=0x806f060, server=0x8060d40, login=0x8060d40, pass=0x8060d40, database=0x8060d40, query=0x8060d40)
    at plugin_mysql.c:79
#2  0x0804da18 in EvalTree (Root=0x806ef20) at evaluator.c:1007
#3  0x0804db29 in Eval (tree=0x806ef20, result=0xbffff010) at evaluator.c:1216
#4  0x0804fc8a in widget_text_update (Self=0x806d768) at widget_text.c:251
#5  0x0804f169 in timer_process (delay=0xbffff0c0) at timer.c:160
#6  0x0804a930 in main (argc=-1073745728, argv=0x805efc0) at lcd4linux.c:636


If it is inserted into plugin_init_mysq(...) then:
# gdb --args lcd4linux -Fq
(gdb) run Starting program: /home/javi/proyectos/lcd4linux/lcd4linux -Fq

Program received signal SIGSEGV, Segmentation fault.
0x08062fd9 in ?? ()
(gdb) bt
#0  0x08062fd9 in ?? ()
#1  0x08054f24 in plugin_init_mysql () at plugin_mysql.c:144
#2  0x08050b81 in plugin_init () at plugin.c:197
#3  0x0804a618 in main (argc=0, argv=0xbffff574) at lcd4linux.c:497

Bye

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Xavier V. <xav...@fr...>]

Hello Michael, hi list.

> >>Fine! I'm expecting results until tomorrow evening :-) 
> > Michael, don't be too quick, you'll make Javi run away ;)
> > Javi, take all your time, lcd4linux prefers quality to speed, unlike
> > other projects I won't list ;)
> Xavier, are you trying to undermine my authority? :-)
Yes :) 

> > BTW: Michael, I've just passed some exams, so I have some time for you
> > next week (before other exams).
> Great! What is your plan?
First, I've 2 weeks of 'void' before the exams. I'm planning :
- searching people to help for dynamic so
- coding the test of the new website
- sleeping :)

Is there something more useful to code for lcd4linux ? I don't think I
can help for namespaces, maybe I could think about input ?

Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] cfg_get() > Segmentation fault

[Xavier V. <xav...@fr...>]

Hello Javi, hello list !

> I've created a MySQL section in lccd4linux.conf in order to get from there the server, login and password parameters to connect to MySQL.
> The problem is wherever I use cfg_get() function I get "Segmentation fault" when running lcd4linux.
> [...]
> Any ideas?
The problem may be in your variables. It will segfault it you use a
plain variable and not a pointer. For example, I used for i2c_sensors :
char *path_cfg=cfg_get(NULL, "i2c_sensors-path", "");

which would become for you :
char *server=cfg_get("mysql", "server", "");

Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] cfg_get() > Segmentation fault

[Michael R. <re...@eu...>]

Hi Javier,

> The problem is wherever I use cfg_get() function I get "Segmentation
> fault" when running lcd4linux.

Can you send me the code?

> Program received signal SIGSEGV, Segmentation fault. 0x08062fd9 in ??

strange. Does "bt" or "u" work?

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

[Lcd4linux-devel] cfg_get() > Segmentation fault

[Javi <ja...@gs...>]

Hi list.

I've created a MySQL section in lccd4linux.conf in order to get from there the server, login and password parameters to connect to MySQL.

The problem is wherever I use cfg_get() function I get "Segmentation fault" when running lcd4linux.

GDB doesn't give me any usefull information:
#  gdb --args lcd4linux -Fq
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
(gdb) run
Starting program: /home/javi/proyectos/lcd4linux/lcd4linux -Fq

Program received signal SIGSEGV, Segmentation fault.
0x08062fd9 in ?? ()
(gdb)

Any ideas?

thanks,bye

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Michael R. <re...@eu...>]

Hi Xavier,

>>Fine! I'm expecting results until tomorrow evening :-)
> 
> Michael, don't be too quick, you'll make Javi run away ;)
> Javi, take all your time, lcd4linux prefers quality to speed, unlike
> other projects I won't list ;)

Xavier, are you trying to undermine my authority? :-)

> BTW: Michael, I've just passed some exams, so I have some time for you
> next week (before other exams).

Great! What is your plan?

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [Lcd4linux-devel] plugin_mysql, to do list.

[Xavier V. <xav...@fr...>]

Hello Javi, hi Michael !

> > Michael, my real full name is Javier Garcia (Stolz is my nick).
> Thanks, fixed.
> What does "Stolz" mean to you? I'm asking because "Stolz" is the german 
> word for "pride" :-)
lol

> > Here is an "improvised" TO DO list :
> > [...]
> Fine! I'm expecting results until tomorrow evening :-)
Michael, don't be too quick, you'll make Javi run away ;)
Javi, take all your time, lcd4linux prefers quality to speed, unlike
other projects I won't list ;)

> > How can I get the variables from the config file, is there any function?
> [...]
> For Numbers, use
> cfg_number(section, key, default,min,max,int *value)
?! I didn't know about this one !

BTW: Michael, I've just passed some exams, so I have some time for you
next week (before other exams).

Bye !
-- 
Xavier VELLO <xav...@fr...>