From: Michael R. <re...@eu...> - 2005-05-02 10:42:22
|
Hi Dan, I just checked in a first try with python: I tried to manage the autoconf stuff for python (dear god, it's not that easy...), and prepared an (empty) python plugin. Could you please tell me your name so I can put it into the copyright notice? As a next step I'm going to add the python wrapper so that the plugin does something senseful. We should continue our discussions on the lcd4linux-devel list, therefore I cc'ed my answer. Could you please subscribve there? Thanks! bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: Dan F. <tem...@ya...> - 2005-05-02 18:35:25
Attachments:
lcd4linuxplugins.py
plugin_python.c
|
Hi lcd4linux team! I've been talking to Michael regarding a python plugin to your cool application. I already got a dynamic layout manager written in python but it is a bit intrusive to the rest of the C-code, so we will be starting off with a simpler python plugin. On Mon, 2005-05-02 at 16:33 +0200, Michael Reinelt wrote: > Hi Dan, > > I've added you to the developer list. Please set up your CVS. If you > need any assistance, please let me know. > Thanx, i got cvs up and running now. As for the first step of the python integration.... I've updated your plugin_python.c file in such a way that it: - has a small footprint (nothing else is changed in the source code) - is independent of the lcd4linux_wrapper* - can operate even when main() is in C - (probably) can co-exist with lcd4linux_wrapper (not tested)* - can execute any global python function that takes a string in and returns a string *lcd4linux_wrapper.c=whatever_name_we_decide.c I also cleaned up the example python code a bit. To make python_plugin.c compile and link i had to add: DEFS+=$(PYTHON_CPPFLAGS) LIBS+=$(PYTHON_EXTRA_LIBS) to the Makefile I also had to: export PYTHONPATH=. in order to make the lcd4linux executable find the python code. When things stabilises a bit i will write a install script that will put that piece of code under /usr/lib/pythonX.X/site-packages where python searches by default. I have not checked in anything of this, I'm just sending you the bits of code you need to do a peer-review of the code. I think that's it. Oh, one more thing. This is an example of what you can put in your lcd4linux.conf to make it all work.. Widget PythonNetDev { class 'Text' expression python::exec('lcd4linuxplugins', 'getNetDev', 'eth0') prefix 'eth0: ' width 23 align 'R' update tick } don't forget the "export PYTHONPATH=." when testing directly from build directory :) /Dan |
From: Michael R. <re...@eu...> - 2005-05-03 11:26:30
|
Hi Dan and others, > As for the first step of the python integration.... > > I've updated your plugin_python.c file in such a way that it: > - has a small footprint (nothing else is changed in the source code) > - is independent of the lcd4linux_wrapper* > - can operate even when main() is in C > - (probably) can co-exist with lcd4linux_wrapper (not tested)* > - can execute any global python function that takes a string in and > returns a string Fine. I just checked it in. btw, the pyt_exec_str() function takes a variable number of arguments, so can a plugin do. Maybe you should change that... > To make python_plugin.c compile and link i had to add: > DEFS+=$(PYTHON_CPPFLAGS) > LIBS+=$(PYTHON_EXTRA_LIBS) > to the Makefile > > I also had to: > > export PYTHONPATH=. Everything should be detected by autoconf now. If you did a 'cvs update', you should run ./bootstrap to ensure everything is updated correctly. Thanks for your contribution! oh, onelast thing: please do not send complete files to the mailing list... I prefer patches against CVS ('cvs -z9 diff -u' is your friend :-) bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: Michael R. <re...@eu...> - 2005-05-04 05:32:55
|
Hi Dan again, > I'm currently trying to steal some threading code from the plugin_exec > to put into the plugin_python. I have this idea of creating a > really slow version of the python::exec function, because then i could > easily create plugins for upload and download status of eMule and > mldonkey (with a polling period of 5 minutes or so). Why sould it be very slow? I think that python gets initialized only once, further calls to python::exec() should be quite fast? If you define an update interval of 5 minutes to the widget calling python::exec, I see no problem here.... Or is the problem that the python script itself may take some time? Then it would be a good idea to call it in a seperate thread... bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: Dan F. <tem...@ya...> - 2005-05-04 08:11:45
|
On Wed, 2005-05-04 at 07:32 +0200, Michael Reinelt wrote: > Hi Dan again, > > > I'm currently trying to steal some threading code from the plugin_exec > > to put into the plugin_python. I have this idea of creating a > > really slow version of the python::exec function, because then i could > > easily create plugins for upload and download status of eMule and > > mldonkey (with a polling period of 5 minutes or so). > > Why sould it be very slow? I think that python gets initialized only > once, further calls to python::exec() should be quite fast? True > > If you define an update interval of 5 minutes to the widget calling > python::exec, I see no problem here.... You are correct, i was not very clear. What i was trying to say is that it needs a slow update interval so that it does not bug the eMule client too much. > Or is the problem that the python script itself may take some time? Then > it would be a good idea to call it in a seperate thread... > And that it needs to be executed in a thread so that it does not slow down the other timing events of the lcd, it is after all a remote call (http) to another host and that may take an undefined amount of time. ( i don't think python itself would make us miss a 'tack' ) So what i'm trying to do is simply a threaded version of the current plugin_python, then i wouldn't have to login and logout of the eMule process every few minutes as the exec version does. /dan |
From: Michael R. <re...@eu...> - 2005-05-04 10:28:28
|
Hi Dan, > And that it needs to be executed in a thread so that it does not slow > down the other timing events of the lcd, it is after all a remote call > (http) to another host and that may take an undefined amount of time. > ( i don't think python itself would make us miss a 'tack' ) okay, got you. You're right. So a threaded version of the python plugin would make much sense. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: Paul K. <pau...@xs...> - 2005-05-10 21:01:09
|
Hi Michael, Michael Reinelt wrote: >Hi Dan, > >I just checked in a first try with python: I tried to manage the >autoconf stuff for python (dear god, it's not that easy...), and >prepared an (empty) python plugin. > > Not sure if this is related to your autoconf stuff but I just got the latest version from cvs and now have a problem. This is the output of the make command: cd . && aclocal-1.4 aclocal: macro `AM_PATH_PYTHON' required but not defined make: *** [aclocal.m4] Error 1 Any ideas? |
From: Michael R. <re...@eu...> - 2005-05-11 04:29:07
|
Hi Paul, > Not sure if this is related to your autoconf stuff but I just got the > latest version from cvs and now have a problem. > This is the output of the make command: > cd . && aclocal-1.4 > aclocal: macro `AM_PATH_PYTHON' required but not defined > make: *** [aclocal.m4] Error 1 Strange. AM_PATH_PYTHON is defined in python.m4. Could you have alook there? Did you try a ./bootstrap? bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: paul k. <pau...@xs...> - 2005-05-11 06:05:44
|
Hi Michael, >Hi Paul, > > > >>Not sure if this is related to your autoconf stuff but I just got the >>latest version from cvs and now have a problem. >>This is the output of the make command: >>cd . && aclocal-1.4 >>aclocal: macro `AM_PATH_PYTHON' required but not defined >>make: *** [aclocal.m4] Error 1 >> >> > >Strange. AM_PATH_PYTHON is defined in python.m4. Could you have alook there? > >Did you try a ./bootstrap? > > > I think it is python.m4. ./bootstrap gives the same error. I also tried the export PYTHONPATH=. that Dan suggested. No luck! Paul |
From: paul k. <pau...@xs...> - 2005-05-11 06:46:40
|
Hi Michael, Ok, I think I know what the problems is. But I am not sure on how to solve it. For some reason the python.m4 in the local directory is not found by aclocal. If I run aclocal -I . to specify the local directory as an include directory, followed by make, it works fine. So there are several possible causes of this different behaviour. 1) you run a different version of aclocal. I use aclocal 1.4 but I noticed that version 1.9 has the python.m4 in its standard macro set. (I still can't figure out how gentoo selects different version of aclocal to use) 2) for some reason you have the local directory included in the aclocal include path by default. Only explaination I found so far is at: http://sources.redhat.com/automake/automake.html#Extending-aclocal Any suggestions? Paul |
From: Michael R. <re...@eu...> - 2005-05-11 19:28:53
|
Hi Paul, > Ok, I think I know what the problems is. But I am not sure on how to > solve it. > For some reason the python.m4 in the local directory is not found by > aclocal. > If I run > > aclocal -I . > > to specify the local directory as an include directory, followed by > make, it works fine. > > So there are several possible causes of this different behaviour. > > 1) > you run a different version of aclocal. I use aclocal 1.4 but I noticed > that version 1.9 has the python.m4 in its standard macro set. (I still > can't figure out how gentoo selects different version of aclocal to use) > > 2) > for some reason you have the local directory included in the aclocal > include path by default. I don't think that you have to include . in the search path. If this would be necessary, aclocal would not find drivers.m4, curses.m4 neither. But I've another strong suspicion: aclocal loads the global python.m4 before the local one (as you said, aclocal-1.9 provides a python.m4). You could try to rename the python.m4 and change the reference in.. in.. wherever it's referenced. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: Paul K. <pau...@xs...> - 2005-05-12 21:06:26
Attachments:
make_output
make_errors
|
Hi Michael, I still think there is something wrong with the configuration files. Here is what I do: - clean get from cvs - ./configure tux lcd4linux # make cd . && aclocal-1.4 aclocal: macro `AM_PATH_PYTHON' required but not defined make: *** [aclocal.m4] Error 1 This definition is cached in aclocal.m4 and is in I have to throw away Makefile, Makefile.in and aclocal.m4 and do ./bootstrap ./configure To recreate the previous files. The do make to start the build process. make But no object files are created and the linking stage fails See the attached files for the make output. I have no idea what goes wrong here :'( bye, Paul Michael Reinelt wrote: >Hi Paul, > > > >>Ok, I think I know what the problems is. But I am not sure on how to >>solve it. >>For some reason the python.m4 in the local directory is not found by >>aclocal. >>If I run >> >>aclocal -I . >> >>to specify the local directory as an include directory, followed by >>make, it works fine. >> >>So there are several possible causes of this different behaviour. >> >>1) >>you run a different version of aclocal. I use aclocal 1.4 but I noticed >>that version 1.9 has the python.m4 in its standard macro set. (I still >>can't figure out how gentoo selects different version of aclocal to use) >> >>2) >>for some reason you have the local directory included in the aclocal >>include path by default. >> >> > >I don't think that you have to include . in the search path. If this >would be necessary, aclocal would not find drivers.m4, curses.m4 neither. > >But I've another strong suspicion: aclocal loads the global python.m4 >before the local one (as you said, aclocal-1.9 provides a python.m4). > >You could try to rename the python.m4 and change the reference in.. in.. >wherever it's referenced. > > >bye, Michael > > > |
From: Michael R. <re...@eu...> - 2005-05-13 07:03:17
|
Hi Paul, > - clean get from cvs > - ./configure > tux lcd4linux # make > cd . && aclocal-1.4 > aclocal: macro `AM_PATH_PYTHON' required but not defined > make: *** [aclocal.m4] Error 1 Well, this is *really* strange. Works here like a charm. > This definition is cached in aclocal.m4 and is in HereI get no definitions about python in aclocal.m4 (neither from plugins.m4 and drivers.m4). Did you try to rename the python.m4 in the lcd4linux directory and to change the sinclude(python.m4) line in configure.in? > But no object files are created and the linking stage fails > See the attached files for the make output. Well, this is even more strange. > make all-am why not simply 'make'? > make[1]: Entering directory `/root/lcd4linux' > source='lcd4linux.c' object='lcd4linux.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/sh ./depcomp \ > gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/python2.3 -D_GNU_SOURCE -Wall -W -g -O2 -c lcd4linux.c looks strange... what's this depcomp? It's in CVS, but with zero size. Maybe something from libtool? bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: paul k. <pau...@xs...> - 2005-05-13 09:24:34
|
Hi Michael, >>- clean get from cvs >>- ./configure >>tux lcd4linux # make >>cd . && aclocal-1.4 >>aclocal: macro `AM_PATH_PYTHON' required but not defined >>make: *** [aclocal.m4] Error 1 >> >> > >Well, this is *really* strange. Works here like a charm. > > > I am not that good with CVS, are there any changes since last night and today? I did this about 30 minutes ago and it builds correctly. However the problem is not solved, yet. Once I change configure.in to remove the i2c detection. (I modified this file a couple of weeks ago without any problems) And then do make. I still get the same error as above. So for some reason regenerating files like configure (from configure.in) and probably Makefile (from Makefile.am) produces incorrect results. >>This definition is cached in aclocal.m4 and is in >> >> >HereI get no definitions about python in aclocal.m4 (neither from >plugins.m4 and drivers.m4) > > Sorry, you are richt. it is not really cached in this file.but there is in a situation a autom4te.cache directory created that, possibly cashes stuff. >Did you try to rename the python.m4 in the lcd4linux directory and to >change the sinclude(python.m4) line in configure.in? > > I did this and that is how I found out that there is some sort of caching somewhere. There are files used when processing configure.in, that are recreated by that same process. There is some sort of circular dependency in there. >>But no object files are created and the linking stage fails >>See the attached files for the make output. >> >> >Well, this is even more strange. > > > >>make all-am >> >> >why not simply 'make'? >make[1]: Entering directory `/root/lcd4linux' > > >>source='lcd4linux.c' object='lcd4linux.o' libtool=no \ >>DEPDIR=.deps depmode=none /bin/sh ./depcomp \ >>gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/python2.3 -D_GNU_SOURCE -Wall -W -g -O2 -c lcd4linux.c >> >> >looks strange... > >what's this depcomp? It's in CVS, but with zero size. Maybe something >from libtool? > > > > All this is probably related to an incorrectly recreated Makefile om my system. All this is really strange. When I take out the AC_PYTHON_DEVEL line in configure.in followed by make, then everything goes well. Inserting AC_PYTHON_DEVEL again, breaks it again. bye, Paul |
From: Dan F. <tem...@ya...> - 2005-05-14 17:05:44
|
Today I updated the cvs after some days of absence and I too got the notorious aclocal error: cd . && aclocal-1.4 aclocal: macro `AM_PATH_PYTHON' required but not defined make: *** [aclocal.m4] Error 1 I got no clue on what consequences this may have, but i simply ran: aclocal-1.5 And then no errors were generated while running make. Anyhow, i just wanted to say that i'm currently working on these things in the python_plugin.c and friends: * Making it support all datatypes the evaluator supports. * Support for any number of arguments (max 9 :) * Adding threading support and the "return value re-use" i mentioned some mails back regards /Dan |
From: Michael R. <re...@eu...> - 2005-05-15 09:38:00
|
Hi Dan, > cd . && aclocal-1.4 > aclocal: macro `AM_PATH_PYTHON' required but not defined > make: *** [aclocal.m4] Error 1 Shit! I really wonder what's wrong here.... > Anyhow, i just wanted to say that i'm currently working on these things > in the python_plugin.c and friends: > * Making it support all datatypes the evaluator supports. > * Support for any number of arguments (max 9 :) > * Adding threading support and the "return value re-use" i mentioned > some mails back Great! bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
From: Michael R. <re...@eu...> - 2005-05-15 09:42:03
|
Hi Paul, > I am not that good with CVS, are there any changes since last night and > today? I did this about 30 minutes ago and it builds correctly. I don't remember. > However the problem is not solved, yet. Once I change configure.in to > remove the i2c detection. (I modified this file a couple of weeks ago > without any problems) And then do make. > I still get the same error as above. So for some reason regenerating > files like configure (from configure.in) and probably Makefile (from > Makefile.am) produces incorrect results. Well, I always use the ./bootstrap commands whenever I change something in the autoconf/make files. Just to be sure... > I did this and that is how I found out that there is some sort of > caching somewhere. There are files used when processing configure.in, > that are recreated by that same process. There is some sort of circular > dependency in there. Hmmm... I have no idea. > When I take out the AC_PYTHON_DEVEL line in configure.in followed by > make, then everything goes well. Inserting AC_PYTHON_DEVEL again, breaks > it again. Someone with deeper knowledge of the autconf/automake subsystem should have a look at the python.m4 file. I can't see any error in there. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |