lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] Working I2C was commited minutes ago

[paul k. <pau...@xs...>]

Thanks Martin,

That did the trick. If I didn't make a mistake, it should be in CVS now.

Paul

Martin Hejl wrote:

> Hi Paul,
>
>>> There are some compiler warnings (about unused arguments) which should
>>> be easy to clean up.
>>>  
>>>
>> I just read Luis his response. Yes it is cosmetic, but also simple to 
>> solve.  :-( I rephrase that, not so
>> simple to solve. I tried the Visual Studio solution (comment out the 
>> unused parameter name) but that changes
>> the warning into an error. Nice!!
>
> adding
> __attribute__ ((unused))
> in front of each unused parameter should make gcc shut up. I just 
> tried it here, and it seems to work with my gcc.
>
> Martin
>
>
>

Re: [Lcd4linux-devel] Working I2C was commited minutes ago

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

Hi Paul,

>> There are some compiler warnings (about unused arguments) which should
>> be easy to clean up.
>>  
>>
> I just read Luis his response. Yes it is cosmetic, but also simple to 
> solve.  :-( I rephrase that, not so
> simple to solve. I tried the Visual Studio solution (comment out the 
> unused parameter name) but that changes
> the warning into an error. Nice!!
adding
__attribute__ ((unused))
in front of each unused parameter should make gcc shut up. I just tried 
it here, and it seems to work with my gcc.

Martin

Re: [Lcd4linux-devel] Working I2C was commited minutes ago

[paul k. <pau...@xs...>]

Hi Michael,

>Works here! (I'm *that* happy :-) At least it compiles, I don't have any
>I2C-display around...
>
>Thanks for the good work
>  
>
That is good news. Here is to some extend what Luis and I did:

- copied relevant information from the kernel i2c headers files to 
lcd4linux_i2c.h
- copied inline i2c functions from a kernel source to the same 
lcd4linux_i2c.h
- removed/changed the kernel i2c include detection from configure.in and 
drivers.m4
- use lcd4linux_i2c.h in drv_generic_i2c.c instead of the kernel includes

All that works fine. Only remaining problem was the speed concerns on 
Luis his system.
To improve this we first removed all delays related to the write cycle 
protocol. The
reason for this is simple. i2c clock is max 100 kHz and changing the 
pcf8574 output takes 2
byte writes (1 address + 1 byte) taking about 20 clock cycles. So 
nanosecond delays are
implicit in the i2c protocol.

In the next step we changed the I2C_nibble function. In this function 3 
seperate i2c writes are made.
Each of these writes is an ioctl call causing a switch over from 
userspace to kernelspace to perform the
actual i2c write. Now we set up an array with all the consequetive 
values to write and then call ioctl
once to write the entire block (3 bytes for a nibble). Additional 
improvement can be achieved by
changing i2c_byte in a similar way. For Luis this improvement was 
sufficient (for now) so we decided to
check in. Luis cleaned up and did the final check-in.

Luis and me are now discussing how we can support two pcf8574 device, so 
we can support displays
in 8-bit mode too.

>>p.s. the python errors are still present, i made NO attempt to fix it,
>>as have no use for that...
>>    
>>
>I'm going to introduce a '--with-python' switch, which is disabled by
>default, so it won't disturb. As soon as this is fixed, I want to
>release 0.10
>  
>
Good idea to add a switch like that. Please remember that I still do 
have this strange problem
with the AC_PYTHON_DEVEL macro in configure.in. If I leave this line in, 
I get that
AC_PYTHON_PATH not found messsage and my entire build related files get 
mixed up.
Making it impossible for me to do a build.
Somehow this AC_PYTHON_PATH macro in python.m4 is blowing up in my face.
I can live with it for now, I don't need python at the moment. But it 
could give a lot of problems
in a release version.

>There are some compiler warnings (about unused arguments) which should
>be easy to clean up.
>  
>
I just read Luis his response. Yes it is cosmetic, but also simple to 
solve.  :-( I rephrase that, not so
simple to solve. I tried the Visual Studio solution (comment out the 
unused parameter name) but that changes
the warning into an error. Nice!!

>Another question: The current i2c code uses a 'real' i2c bus (which I
>don't have in my notebook, at least I cannot connect anything to it).
>I've seen in serdisplib that it's possible to 'emulate' a i2c bus on the
>serial port; and I got a (very strange) display from Pollin yesterday,
>which is also driven by i2c, and their sample program use the parallel
>port for i2c emulation....
>
>Should we add support for it?
>  
>
I don't think we should. Most certainly not right now. I remember seeing 
a kernel module somewhere that
provided this i2c over parallel port emulation. That could be a nice 
solution for it.

Kind regards,

Paul

PS: Luis, thanks for the clean-up and the check-in

Re: [Lcd4linux-devel] Working I2C was commited minutes ago

[Luis C. <lfc...@lf...>]

Michael Reinelt wrote:

>Hi alltogether,
>
>  
>
>>Since me and Paul have been busy making this I2C sucker work for all of
>>us (yes, that includes Michael).
>>    
>>
>Works here! (I'm *that* happy :-) At least it compiles, I don't have any
>I2C-display around...
>
>Thanks for the good work!
>  
>
Finally!!!

>  
>
>>p.s. the python errors are still present, i made NO attempt to fix it,
>>as have no use for that...
>>    
>>
>I'm going to introduce a '--with-python' switch, which is disabled by
>default, so it won't disturb. As soon as this is fixed, I want to
>release 0.10
>
>  
>
Yes, that would be great.

>There are some compiler warnings (about unused arguments) which should
>be easy to clean up.
>
>  
>
Well, we are using the HD44780 framework but we no longer use the 
'delay' argument.
We may setup something that would take care of that. It is cosmetic only :)

>Another question: The current i2c code uses a 'real' i2c bus (which I
>don't have in my notebook, at least I cannot connect anything to it).
>I've seen in serdisplib that it's possible to 'emulate' a i2c bus on the
>serial port; and I got a (very strange) display from Pollin yesterday,
>which is also driven by i2c, and their sample program use the parallel
>port for i2c emulation....
>
>Should we add support for it?
>
>  
>
Well, we do use a real i2c bus for the moment.

The paralell port can be used as an emulated i2c, but code would have to 
be written, and our current framework is not ready for that.
It may become similar to the HD44780 with all the quirky modes (4bit, 
8bit, ppdev, pure paralell...).

For my embedded board, i'm also thinking to add temperature reading, as 
the sensor is also present in the other I2C bus. And no, i will not use 
lm_sensors for that. The device is not supported and the whole 
lm_sensors is kinda bloated for what I need. To give you an idea, 
reading the temperature is a 6 liner .
---------------------
    i2c_device = open("/dev/i2c-1",O_RDWR);
    ioctl(i2c_device,I2C_SLAVE, (0x90>>1) );
    temp = i2c_smbus_read_word_data(i2c_device, 0);
    temp = ((((temp && 0x00FF)<< 9) + (temp >> 8)) >> 3) / 2;
    printf("temperature: %i \n",temp);
    close(i2c_device);
---------------------

>bye, Michael
>
>  
>
We are also planning to make another mode for this I2C driver, which 
would use two PCF8574 I2C I/O extenders, in order to provide an 8 bit 
interface to the LCD display, plus a small keyboard. Thus, one of the 
things we are curious about is how are you going to implement keyboard 
support to LCD4Linux. Our keyboard will probably be very simple, 4 or 6 
keys.

Luis Correia

Re: [Lcd4linux-devel] Working I2C was commited minutes ago

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

Hi alltogether,

> Since me and Paul have been busy making this I2C sucker work for all of
> us (yes, that includes Michael).
Works here! (I'm *that* happy :-) At least it compiles, I don't have any
I2C-display around...

Thanks for the good work!

> p.s. the python errors are still present, i made NO attempt to fix it,
> as have no use for that...
I'm going to introduce a '--with-python' switch, which is disabled by
default, so it won't disturb. As soon as this is fixed, I want to
release 0.10

There are some compiler warnings (about unused arguments) which should
be easy to clean up.

Another question: The current i2c code uses a 'real' i2c bus (which I
don't have in my notebook, at least I cannot connect anything to it).
I've seen in serdisplib that it's possible to 'emulate' a i2c bus on the
serial port; and I got a (very strange) display from Pollin yesterday,
which is also driven by i2c, and their sample program use the parallel
port for i2c emulation....

Should we add support for it?


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] Working I2C was commited minutes ago

[Luis C. <lfc...@lf...>]

> p.s. the python errors are still present, i made NO attempt to fix it, 
> as have no use for that...
>
More python errors would have occoured as I accidently removed the 
detection code from configure.in

Commited the fix just now :)

Luis Correia

[Lcd4linux-devel] Working I2C was commited minutes ago

[Luis C. <lfc...@lf...>]

Hi!

I hope i did not make any mess this time.

Since me and Paul have been busy making this I2C sucker work for all of 
us (yes, that includes Michael).

First approach was to remove the dependency from the I2C kernel 
includes, by having our own file (lcd4linux_i2c.h).
Then the autoconf files were tweaked in order to always detect I2C (this 
is a matter that needs ot be addressed by someone with more auto* 
knowledge).

Finally, the drv_generic_i2c and the drv_HD44780 files were cleaned up.
Please test the current CVS code as some mistakes may have been introduced.

p.s. the python errors are still present, i made NO attempt to fix it, 
as have no use for that...

Luis Correia

Re: [Lcd4linux-devel] LCD4Linux CVS=>SVN

[Maxime P. <max...@bu...>]

> Even if SF will provide svn someday, I guess there will be still a
> delay. And I really *hate* this delay.....

Anyway, anyhow, your SVN repository is waiting for data since the Trac
environment has been set up.

If you need more people to be able to commit, just send me the result
of 'htpasswd2 -n <username>'.

Regards,
- Sam
-- 
/ Maxime Petazzoni - <max...@bu...> - bulix.org |
| Zwe (zwe.bulix.org) - Gobelins : http://gobelins.nekeme.net |
| Gpg Id: 0x83E6AE0D  - Jabber: sa...@ja... ________________/

Re: [Lcd4linux-devel] LCD4Linux CVS=>SVN

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

Hi all,

> IIRC, LCD4Linux left Sourceforge because of it's poor reliability ...

No, that's not entirely true. First, I did not really "leave" SF.
Downloads, CVS, Mailing Lists are still there.

There's been one reason for moving the web pages to Sam: The wiki.

There will be another reason for moving to CVS to SVN at bulix: The
delay between developer and anonymous cvs servers.

Even if SF will provide svn someday, I guess there will be still a
delay. And I really *hate* this delay.....


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] LCD4Linux CVS=>SVN

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

Hi Maxime/Sam,

> One of the advantages of Free Software is that you have to choice of
> the tools you want to use. Some projects choose CVS, others Arch,
> others Subversion, ... It's a diversity we have to live with, and it's
> far from being a harm.
I'm not saying that diversity is harmful - but when one has a limited 
amount of time to work on stuff like lcd4linux, one needs to chose what 
one spends one's time on - and I'd rather work on code (or even 
documentation) than learn a new tool, just because it's deemed superior 
to the one I already know how to use. Now, if there's a specific feature 
in the new tool that I need/would benefit from, of course a switch makes 
sense. And if Michael feels he would benefit from switching to svn, I 
guess he should.

Also, remember that I didn't tell Michael he shouldn't switch - I just 
expressed my point of view that if lcd4linux was switching to a 
different tool to manage the code, I would no longer be able to 
participate in development (and I even pointed out that I haven't done 
so in the recent past anyway, so the effect on the project would be none).

> When I'm on the 'user side', I don't see much difference between 'svn
> up' and 'cvs up'.
Well, I guess both cvs and svn offer more than just the "update" command 
and I'd be extremely surprised if switching to svn on the client side 
would be as simple as replacing "cvs" in each call with "svn". Having 
briefly glanced over the svn manual, I find that pretty much every 
command beyond update/add/commit is (even if only slightly) different, 
and that features like branching/merging are _rather_ different. Let 
alone workspace administration, but I agree with you that this is not 
part of the "user side" (it can be for CVS, but only because one is 
working around a limitation of CVS).

Anyhow, if there are subtle differences, that's the most dangerous part 
to me. I want to avoid trashing a project at work by using svn commands 
instead of cvs commands (or vice versa). If I could switch _everything_ 
I work on to svn, I probably would (even though I'd also look at 
monotone or arch first, since I'd also like the possibility of some sort 
of "replication" between local and remote repositories).

> Svn is nice. I've been using it since it have been declared stable by
> it's developpers (~ 18 months ago), and I can tell you that the two
> features you are pointing out are not the ones I'd choose to show
> Subversion superiority on CVS. 
I think you misunderstood me. To me, CVS does the job I need it to do. 
It has some quirks that are annoying at times (quirks that svn doesn't 
have) but the quirks are not bad enough to justify switching to svn (to 
me - I'm aware that other people have other preferences).
Wether I'm using the most superior product available doesn't really 
matter to me, as long as the tool I'm using gets the job done.

Maybe I wasn't really clear with what I was trying to say in my mail - I 
have nothing against subversion. I've heard lots of good things about 
it. It can do a lot that CVS can't do, and it does some things better 
than CVS.  But I know CVS, and with it I can do what I need to do. I 
don't have the spare time to learn every tool that comes up and is 
better than the tools I already use.

> Of course, handling of binary files is
> important, but in my opinion, moving and copying files or entire
> directories without loosing the history (svn mv, svn cp) is even more
> important. 
Depends on one's point of view/needs, I guess. Maybe I'm just too used 
to CVS by now - since to me, doing a rename of a file as a remove and 
subsequent add is not a problem. Indeed, to CVS there is no connection 
between the old file and the new one (which is what I assume you're 
referring to with "loosing the history"), but I haven't come across an 
instance yet where that was a problem. I agree that subversions way of 
handling that is much better than the approach of CVS.

>>But if you decide to switch, you may also want to take a look at the
>>latest news from sourceforge - from what I've heard, they're working
>>on offering svn.
> 
> 
> IIRC, LCD4Linux left Sourceforge because of it's poor reliability ...
The webservers are definately unreliable at the moment (and have been 
for quite a while) - but I'm not aware of any major issues with the 
cvs-servers (other than that the backup servers, which are used for 
anonymous access, always take a couple of ours to sync).
And again, I didn't tell Michael he shouldn't use bulix.org svn servers 
(I assume they're yours) - I just told him that he "may also want to 
check out" the new developments on SF.

Martin

Re: [Lcd4linux-devel] LCD4Linux CVS=>SVN

[Maxime P. <max...@bu...>]

Hi,

> Not that it would have any impact on development of lcd4linux, but
> for me, a switch to subversion would mean that I'll no longer track
> the latest development, for the time being.  That's simply because I
> have projects that are on CVS (and will definately stay that way for
> quite a while), plus I'm in charge of running several CVS servers
> (work related stuff), and I don't really want to have to use two
> similar but different tools.

One of the advantages of Free Software is that you have to choice of
the tools you want to use. Some projects choose CVS, others Arch,
others Subversion, ... It's a diversity we have to live with, and it's
far from being a harm.

When I'm on the 'user side', I don't see much difference between 'svn
up' and 'cvs up'.

> From what I've read, svn is pretty nice - but to be honest, none of
> the problems that cvs has and that svn fixes (handling of binary
> files and versioning of directories are the two that bug me the
> most) are bad enough to spend the extra time migrating tons of
> projects and learning a new tool (to _me_, that is).

Svn is nice. I've been using it since it have been declared stable by
it's developpers (~ 18 months ago), and I can tell you that the two
features you are pointing out are not the ones I'd choose to show
Subversion superiority on CVS. Of course, handling of binary files is
important, but in my opinion, moving and copying files or entire
directories without loosing the history (svn mv, svn cp) is even more
important. Branching and merge algorithms are also way more powerful
than in CVS.

> But if you decide to switch, you may also want to take a look at the
> latest news from sourceforge - from what I've heard, they're working
> on offering svn.

IIRC, LCD4Linux left Sourceforge because of it's poor reliability ...

Regards,
- Sam
-- 
/ Maxime Petazzoni - <max...@bu...> - bulix.org |
| Zwe (zwe.bulix.org) - Gobelins : http://gobelins.nekeme.net |
| Gpg Id: 0x83E6AE0D  - Jabber: sa...@ja... ________________/

Re: [Lcd4linux-devel] LCD4Linux CVS=>SVN

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

Hi Michael,

> I think it would be a good idea to switch from CVS to SVN someday. Is
> there anybody out there who has arguments against such a switch?
Not that it would have any impact on development of lcd4linux, but for 
me, a switch to subversion would mean that I'll no longer track the 
latest development, for the time being.
That's simply because I have projects that are on CVS (and will 
definately stay that way for quite a while), plus I'm in charge of 
running several CVS servers (work related stuff), and I don't really 
want to have to use two similar but different tools.

 From what I've read, svn is pretty nice - but to be honest, none of the 
problems that cvs has and that svn fixes (handling of binary files and 
versioning of directories are the two that bug me the most) are bad 
enough to spend the extra time migrating tons of projects and learning a 
new tool (to _me_, that is).

But if you decide to switch, you may also want to take a look at the 
latest news from sourceforge - from what I've heard, they're working on 
offering svn.

Just my two cents - not really being a contributor at the moment, I'm 
obviously not telling you that you shouldn't switch to svn.

Martin

[Lcd4linux-devel] LCD4Linux CVS=>SVN

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

Hi there,

I started a new small project in the last days (http://tig.bulix.org),
which is hosted by Sam in a trac environment (Thanks again, Sam!)

I decided to use trac's Subversion (svn) support for it, and I must say
that I really like svn, and especially the graphical diff's trac shows
in the 'timeline' (Have a look at tig's timeline).

I think it would be a good idea to switch from CVS to SVN someday. Is
there anybody out there who has arguments against such a switch?

It will be done *after* 0.10 is released.

comments welcome!


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] getting rid of python dependency

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

Hi Martin,

> I have no doubt. But I guess it's also very difficult to meet the wishes
> of such a diverse userbase - people like me want it to be as small as
> possible, without any dependencies to other packages. Other people want
> to make lcd4linux part of a bigger application, and hence need
> python/perl/c++/Java/whatever bindings...

Well, it wouldn't be that difficult if autoconf would do things like I
want it to do. But as always - the computer does what you write, not
what you want :-)

> I guess it's just one of the usual problems, where "configure" assumes
> that the box that the program is being compiled on is the same as the
> one it will run on.
You are right. Good point - I forgot about cross-compiling.

For the moment, the '--with-plugins=all,!python' looks like a good
workaround. But for the future, when there will be more python support
in lcd4linux, a '--without-python' switch will be the Right Thing (tm).


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] getting rid of python dependency

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

Hi Martin,

> Attached is a patch (against HEAD in CVS) for plugins.m4 which seems to
> fix the problem that something like "--with-plugins=all,!mysql" didn't
> work.

uh-oh... evil, evil bug....

fixed and checked in. Thanks!


bye, Michael
-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] getting rid of python dependency

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

Hi Michael,

good timing - I just sent off the other mail... :-)

> I assure you that I always have you "embedded guys" in mind.
I have no doubt. But I guess it's also very difficult to meet the wishes 
of such a diverse userbase - people like me want it to be as small as 
possible, without any dependencies to other packages. Other people want 
to make lcd4linux part of a bigger application, and hence need 
python/perl/c++/Java/whatever bindings...


> There *should* be no problem, because autoconf (especially the
> python.m4) is meant to check if you have python (-devel), and
> deactivates all that python stuff if there is none.
Right - but autoconf seems to find the python stuff installed on my 
devel box, which is there just fine, but isn't found during the actual 
compile (since it's _not_ installed in my sandbox for compiling/linking 
against uClibc). Remember, I'm doing a little bit of a cross-compile, so 
whenever configure picks up something that's installed on the devel box 
but not in the sandbox for uClibc, I'm in trouble.

I guess it's just one of the usual problems, where "configure" assumes 
that the box that the program is being compiled on is the same as the 
one it will run on.

> Or did I miss something?
No - I just didn't use the --with-plugins directive properly. Once I 
used that the compile worked (by specifying every plugin except python), 
and with the patch I sent in my previous mail, it also works with 
"all,!python".

Martin

Re: [Lcd4linux-devel] getting rid of python dependency

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

Hi again,

sorry for the noise - I managed to get it to work by using the 
"--with-plugins" directive properly (for some reason I missed that 
yesterday).

Attached is a patch (against HEAD in CVS) for plugins.m4 which seems to 
fix the problem that something like "--with-plugins=all,!mysql" didn't work.

Martin

Re: [Lcd4linux-devel] getting rid of python dependency

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

Hi Martin,

> I know that with all the work everybody put in to get python support
> working, I'm not going to make myself very appreciated in asking that -
> but how does one remove the dependency on python from lcd4linux? I
> didn't see a "--without-python" in the configure script, and the
> platform that I'm building lcd4linux for (LEAF Bering uClibc) will
> _never_ support Python (well, unless it tosses aside one of its major
> project goals - being compact enough to fit on a floppy).

I assure you that I always have you "embedded guys" in mind.

> Of course, I could patch all python support out of the autoconf files -
> but I guess that's not quite the way it should be.
There *should* be no problem, because autoconf (especially the
python.m4) is meant to check if you have python (-devel), and
deactivates all that python stuff if there is none.

There are some problems at the moment with the python stuff, but they
are autoconf related, and I hope they will get solved soon.

Or did I miss something?


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] getting rid of python dependency

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

Hi everybody,

I know that with all the work everybody put in to get python support 
working, I'm not going to make myself very appreciated in asking that - 
but how does one remove the dependency on python from lcd4linux? I 
didn't see a "--without-python" in the configure script, and the 
platform that I'm building lcd4linux for (LEAF Bering uClibc) will 
_never_ support Python (well, unless it tosses aside one of its major 
project goals - being compact enough to fit on a floppy).

Of course, I could patch all python support out of the autoconf files - 
but I guess that's not quite the way it should be.

Any ideas?

Martin

Re: [Lcd4linux-devel] I2C finally works for me!...

[Luis C. <lfc...@lf...>]

Luis Correia wrote:

> ...but it is too slow to be useable
>
> My initial thoughts were correct, something (not really lcd4linux) is 
> slowing lcd4linux down. It may be my board, it's I2C bus driver or my 
> whole i2c implementation inside lcd4linux.
> Don't get me wrong, for pretty much static text it is ok, but not for 
> something that moves (OS widget for an example).
>
> During the next days i'll try to profile it and see what is causing 
> this but I guess it is the expected slow I2C bus.
> Paul will not agree with my assumptions, as his system runs OK :)
>
> Luis Correia


Oh, I forgot, to achieve this I had to change some lines inside 
drv_generic_i2c.c, but nothing major.
I'll work with Paul to try and find a common sense in my changes. (this 
basicly means, 'if it works for Paul too' :)

Luis Correia

[Lcd4linux-devel] I2C finally works for me!...

[Luis C. <lfc...@lf...>]

...but it is too slow to be useable

My initial thoughts were correct, something (not really lcd4linux) is 
slowing lcd4linux down. It may be my board, it's I2C bus driver or my 
whole i2c implementation inside lcd4linux.
Don't get me wrong, for pretty much static text it is ok, but not for 
something that moves (OS widget for an example).

During the next days i'll try to profile it and see what is causing this 
but I guess it is the expected slow I2C bus.
Paul will not agree with my assumptions, as his system runs OK :)

Luis Correia

Re: [Lcd4linux-devel] Re: Python bindings for lcd4linux?

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

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

Re: [Lcd4linux-devel] Re: Python bindings for lcd4linux?

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

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

[Lcd4linux-devel] =?iso-8859-1?Q?Re:_C=EDALLlS_V=C1LLlUM_VlAGGR=C0?=

[Rajiv A. <Ac...@jb...>]

Hello, 

Blood's thoughts were upon this and other things as he lounged
His lordship laughed.  You fool, he said.  Do you dream that I
concerned to abate the pride of Spain and plant the Lilies of Fra
his elegant suit of violet taffetas with gold-embroidered
Half stunned by that reverberating thunder, and thrown off her
I don't think a navigator will be needed this time, Peter.
man.
What am I, then? she asked him, laughing.
headlong, into speech, gasping, breathless.
have made my peace with the Governor.  I tell you I know the way
at once.  But because he liked the proposal he consented to consi
So I should have thought.  But I have the information from a Maj
Within a mile and a half to westward of the fort, and within a


Have a nice day.

Re: [Lcd4linux-devel] Re: Python bindings for lcd4linux?

[Dan F. <tem...@ya...>]

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