Yeah, works for Eterm cvs too.
Forgot to mention one thing. Step 0 was I had to copy my system
libtool.m4 file to top_srcdir aclocal.m4 before libtoolize was run.
cp /usr/share/aclocal/libtool.m4 ./aclocal.m4
Then, the rest went fine.
On Wed, 2004-12-29 at 06:50 -0500, Peter Hyman wrote:
This is becoming a pain. :(
If everything else didn't work 100% without any screwing around I would
probably have given up already.
I received a response from the Mono list that they use SIGPWR for their
garbage collector.
And that is interfering with this line:
On Wednesday 29 December 2004 01:44 am, Michael Jennings wrote:
On Tuesday, 28 December 2004, at 19:43:36 (-0500),
Mike Frysinger wrote:
here's a small python snippet that reproduces this behavior:
$ python -c 'print \x1b[31;06mhi dad;'
^^
This is correct
In case there still are a few out there using e16 :)
I have been messing around with a number of things, until now in a
separate CVS branch. This has now been merged into the trunk.
0.16.8 contains (at least internally) major changes wrt. 0.16.7.
I believe it is quite stable, but there may well be
On Wednesday, 29 December 2004, at 14:09:34 (-0500),
Mike Frysinger wrote:
ive looked in the past for a reference manual for these kind of
modifiers but was unable to find any ...
have you a URL or resource handy ? :)
Depends. For xterm, here's what you want:
On Wednesday, 29 December 2004, at 06:50:06 (-0500),
Peter Hyman wrote:
Now I know why you affectionately refer to the autoF*C* programs as
such!
You're just *beginning* to see why. Trust me on that. :-]
My problem with building libast (and probably Eterm, but I have
gotten there yet), is
This fixes a SEGFPE when a new app has iccm info, doesn't request a pos
and have a size bigger/same than the container. (the SEGFPE is caused by
a modulo (0))
Cheers,
Antoine Perdaens
Index: e_border.c
===
RCS file:
Hello,
I debianized e, elicit, evidence, engage. I know your repository because
I could have a try of e17 thanks to you ;-)
Installing the debs is one thing ; another thing is to be able to
compile fresh e17 from CVS. But for these applications the debian
directory is empty on the CVS... I
The xpm buffer overflow reported for imlib also appears to affect
imlib2. You can read the details at: http://bugs.debian.org/285138
Thanks.
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition
On Thu, 16 Dec 2004, Alex wrote:
I know that I have seen documentation for the APIs that the libraries
implement, but I can't find it anymore and a search of the archive
hasn't turned it up either. Can someone point me in the right direction?
the documentation on the site is a bit
[EMAIL PROTECTED] wrote:
On Fri, 17 Dec 2004 16:15:16 EST, Frederick Heckel said:
What happened here is that there was an empty directory sitting in my
mapping/ dir. It looks like e_app_new is fine with directories, but it
doesn't actually fill out the app-winclass field if
I know you guys are busy with stuff, so when you have time
I've been creating C# bindings to EWL to extend the library to Mono and
I'm having a little trouble.
The problem is I can invoke the ewl_init() and ewl_main(), but
ewl_main_quit() doesn't kill the loop.
The only thing that breaks me
that bug was fixed a while ago - please update :)
DM wrote:
Good time of day!
After today's cvs chkout, i receive strange error on compilation in
apps/e/bin:
if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/opt/e17/include -I../..
-I../../src/bin -I../../src/lib -I/opt/e17/include -I/opt/e17/include
Hehe, were you able to sort out your issues then?
On Thu, 23 Dec 2004 09:00:54 -0500 (EST), Nigel Benns
[EMAIL PROTECTED] wrote:
Apparently I can't spell sourceforge!!!
Hi Nathan,
Thats the weird thing... I've basically recreated the Helloworld C program
in the ewl book, and it doesn't
Hello list,
after a ./autogensh in e17/libs/engrave and a make i got the error :
engrave.l:5:35: libengrave_la-engrave.h: No such file or directory
This file is not in my local Reprository (cvs from 08:30 CET today)
How can i solve this ?
Thanks to the Enlightenment Team for this great work
Try setting one of your language variables to en_US.UTF-8
That shushed the error message for me. Regardless, that is a non-fatal
warning and should have nothing to do with your problem afaik.
On Tue, 28 Dec 2004 20:53:41 +, Peter Hyman [EMAIL PROTECTED] wrote:
No matter what I type,
That header file is generated by the build process. If its not there
then either flex or bison didn't run, can't remember which. You should
see some kind of error earlier in the build process.
dan
On Fri, 2004-12-24 at 08:51 +0100, Antonio Palladini wrote:
Hello list,
after a ./autogensh in
17 matches
Mail list logo
