Re: [E-devel] E SVN: discomfitor IN trunk/eina: . m4
and stop using AS_IF
Vincent
On Sun, 8 Aug 2010, Enlightenment SVN wrote:
Log:
split out spinlock detection to separate macro for readability, add rwlock
detection macro
***no functional changes***
Author: discomfitor
Date: 2010-08-08 12:20:07 -0700 (Sun, 08 Aug 2010)
New Revision: 50910
Modified:
trunk/eina/configure.ac trunk/eina/m4/efl_threads.m4
Modified: trunk/eina/configure.ac
===
--- trunk/eina/configure.ac 2010-08-08 19:03:34 UTC (rev 50909)
+++ trunk/eina/configure.ac 2010-08-08 19:20:07 UTC (rev 50910)
@@ -84,7 +84,7 @@
EFL_CHECK_CPU_SSE2([have_sse2=yes], [have_sse2=no])
EFL_CHECK_CPU_ALTIVEC([have_altivec=yes], [have_altivec=no])
-EFL_CHECK_THREADS([yes],
+EFL_CHECK_THREADS(
[
if test x${_efl_have_posix_threads} = xyes ; then
have_threads=POSIX
@@ -96,9 +96,9 @@
fi
fi
],
- [have_threads=no],
- [have_posix_threads_spinlock=yes],
- [have_posix_threads_spinlock=no])
+ [have_threads=no])
+EFL_CHECK_SPINLOCK([have_posix_threads_spinlock=yes],
[have_posix_threads_spinlock=no])
+EFL_CHECK_RWLOCK([have_posix_threads_rwlock=yes],
[have_posix_threads_rwlock=no])
### Additional options to configure
@@ -591,11 +591,10 @@
echo Maximum log level: ${with_max_log_level}
echo Report string usage..: ${have_stringshare_usage}
echo Default mempool..: ${have_default_mempool}
-echo $ECHO_N Thread Support...: ${have_threads}$ECHO_C
+echo Thread Support...: ${have_threads}
if test ${have_threads} = POSIX ; then
- echo (spinlock: ${have_posix_threads_spinlock})
-else
- echo
+echo spinlock...: ${have_posix_threads_spinlock}
+echo rwlock.: ${have_posix_threads_rwlock}
fi
echo Amalgamation.: ${do_amalgamation}
echo Iconv support: ${have_iconv}
Modified: trunk/eina/m4/efl_threads.m4
===
--- trunk/eina/m4/efl_threads.m4 2010-08-08 19:03:34 UTC (rev 50909)
+++ trunk/eina/m4/efl_threads.m4 2010-08-08 19:20:07 UTC (rev 50910)
@@ -1,13 +1,13 @@
dnl Copyright (C) 2010 Vincent Torri vtorri at univ-evry dot fr
-dnl That code is public domain and can be freely used or copied.
+dnl rwlock code added by Mike Blumenkrantz mike at zentific dot com
+dnl This code is public domain and can be freely used or copied.
dnl Macro that check if POSIX or Win32 threads library is available or not.
-dnl Usage: EFL_CHECK_THREADS(want_pthread_spin[, ACTION-IF-FOUND [,
ACTION-IF-NOT-FOUND]])
+dnl Usage: EFL_CHECK_THREADS(ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
dnl Call AC_SUBST(EFL_PTHREAD_CFLAGS)
dnl Call AC_SUBST(EFL_PTHREAD_LIBS)
-dnl Define EFL_HAVE_POSIX_THREADS or EFL_HAVE_WIN32_THREADS, and
EFL_HAVE_THREADS
-dnl Define EFL_HAVE_POSIX_THREADS_SPINLOCK
+dnl Defines EFL_HAVE_POSIX_THREADS or EFL_HAVE_WIN32_THREADS, and
EFL_HAVE_THREADS
AC_DEFUN([EFL_CHECK_THREADS],
[
@@ -138,11 +138,29 @@
AC_DEFINE([EFL_HAVE_POSIX_THREADS], [1], [Define to mention that POSIX
threads are supported])
fi
+
+if test x${_efl_enable_win32_threads} = xyes ; then
+ _efl_have_win32_threads=yes
+ AC_DEFINE([EFL_HAVE_WIN32_THREADS], [1], [Define to mention that Win32
threads are supported])
+fi
+
+if test x${_efl_have_posix_threads} = xyes || test
x${_efl_have_win32_threads} = xyes ; then
+ AC_DEFINE([EFL_HAVE_THREADS], [1], [Define to mention that POSIX or Win32
threads are supported])
+fi
+
+AS_IF([test x$_efl_have_posix_threads = xyes || test
x$_efl_have_win32_threads = xyes], [$1], [$2])
+])
+
+dnl Usage: EFL_CHECK_SPINLOCK(ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
+dnl Defines EFL_HAVE_POSIX_THREADS_SPINLOCK
+AC_DEFUN([EFL_CHECK_SPINLOCK],
+[
+
dnl check if the compiler supports pthreads spinlock
_efl_have_posix_threads_spinlock=no
-if test x${_efl_have_posix_threads} = xyes test x$1 = xyes ; then
+if test x${_efl_have_posix_threads} = xyes ; then
SAVE_CFLAGS=${CFLAGS}
CFLAGS=${CFLAGS} ${EFL_PTHREAD_CFLAGS}
@@ -166,24 +184,55 @@
AC_MSG_CHECKING([whether to build POSIX threads spinlock code])
AC_MSG_RESULT([${_efl_have_posix_threads_spinlock}])
-if test x${_efl_enable_posix_threads} = xyes test
x${_efl_have_posix_threads_spinlock} = xno test x$1 = xyes ; then
+if test x${_efl_enable_posix_threads} = xyes test
x${_efl_have_posix_threads_spinlock} = xno ; then
AC_MSG_WARN([POSIX threads support requested but spinlocks are not
supported])
fi
if test x${_efl_have_posix_threads_spinlock} = xyes ; then
AC_DEFINE([EFL_HAVE_POSIX_THREADS_SPINLOCK], [1], [Define to mention that
POSIX threads spinlocks are supported])
fi
+AS_IF([test x$_efl_have_posix_threads_spinlock = xyes], [$1], [$2])
+])
-if test x${_efl_enable_win32_threads} = xyes ; then
- _efl_have_win32_threads=yes
- AC_DEFINE([EFL_HAVE_WIN32_THREADS], [1], [Define to
Re: [E-devel] python2.5-elementary on N900
On Sat, Aug 7, 2010 at 2:35 PM, Laszlo KREKACS laszlo.krekacs.l...@gmail.com wrote: Hi, Hey there, With who can I collaborate to get python2.5-elementary compiled on Nokia N900? Seems like it is in extras-devel repository, but import elementary fails in a python program. It's been quite some time since I last touched the maemo packaging, so packages on the extra-devel repository are very much outdated. And Elementary was uploaded as an experimental package, so I didn't spend much time testing and improving. I'll be working on the packages during this week, since Canola has been ported to be using Ethumb and Elementary instead of deprecated Epsilon and Etk. Also there are many packages, which cant be installed: libelementary0-dev libecore0-dev libevas0-dev libeet1-dev libedje0-dev Actually it doesn't make much sense to install -dev libraries on the device itself. They are meant to be used only in the SDK environment, I would really like to help out, to get python-elementary running. If somebody could point me to some tutorial how to package it to the N900, I would do it. Im on a ubuntu 9.10 box. (I can install anything in virtualbox if required). The first step is to install Scratchbox and Maemo SDK. You can find more instructions on http://maemo.org/development/. The package metadata for Maemo EFL is maintained as a separate project on maemo garage https://garage.maemo.org/projects/maemo-efl. What I usually do is to create the source packages with the gen-deb-src.sh script and then build them inside the scratchbox environment. After some basic QA, the sources are uploaded to the Maemo AutoBuilder which builds and include them to the extras-devel automatically. Best regards, Etrunko -- Eduardo de Barros Lima ebl...@gmail.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Textblock format removing behavior - consulting
* Tom Hacohen tom.haco...@partner.samsung.com [2010-08-08 11:49:45 +0300]: Hey all, Consider the following text: bbla/b (which of course shows just bla bold). At the moment, erasing the b will leave the text as: bla/b and erasing the /b will leave the text as: bbla. I find this behavior very odd, because there's no way to really reuse the other part in a sane manner. Especially since the user is the one that's removing the first part (pressing delete on the keyboard for example) while it's the widget that will have to know it still exists and reuse it in a smart way. In other words, not only it's confusing, it can cause a lot of mess. Important notice: those formats just point to letters, deleting them means deleting the letters they point to. There are two approaches (I can think of) to solve this: 1. When erasing the b (it's letter) also erase the /b, which is ok, but not perfect. 2. When trying to erase the b (it's letter), don't erase the /b but instead advance b to the next letter and only erase the /b (and the b) when b and /b point to the same place, i.e when they are not used. Yeah, #2 seems the way to go to me too. It's the behavior of most word processors out there. I find the second solution more correct, just wanted to hear what you think since it's changing the behavior of the textblock object a bit. Thanks, Tom. P.S Accidentally sent it to e-svn :P -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje file format breakage
If I remember correctly there are some edj (i.e already compiled edc's) in svn. Don't forget to update them, or better yet, create a Makefile for them and start shipping only edc's. -- Tom. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje file format breakage
On 08/09/2010 01:49 PM, Tom Hacohen wrote: If I remember correctly there are some edj (i.e already compiled edc's) in svn. Don't forget to update them, or better yet, create a Makefile for them and start shipping only edc's. That would be the preferred way (edc), so that future things like that do not require too much manual updating...the edj files can just be remade during the build process. dh -- Tom. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje file format breakage
On Mon, 09 Aug 2010 13:56:03 -0400 Christopher Michael cpmicha...@comcast.net wrote: On 08/09/2010 01:49 PM, Tom Hacohen wrote: If I remember correctly there are some edj (i.e already compiled edc's) in svn. Don't forget to update them, or better yet, create a Makefile for them and start shipping only edc's. That would be the preferred way (edc), so that future things like that do not require too much manual updating...the edj files can just be remade during the build process. I have always insisted that we store edc source files in SVN and not edj files. This is yet one more good reason to. Raster said that edj is an image format like PNG, but PNG is not compiled from source, so that argument is not a good one. edj files are compiled from source, so we should ALWAYS put the source in SVN and suitable makefiles to compile them. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] library todos
On Sunday, 08 August 2010, at 14:12:51 (+1000), David Seikel wrote: I'd like to get some thoughts from other people on the ML about a discussion we just had in irc. Specifically, I suggested that when people begin work on a project, they should sign off in the TODO file with their dev name and the task that they are working on, then remove the line when they finish. This would help people keep track of who is doing what and hopefully prevent trators. What is trators? It's not a real word (at least not in English). Can't figure out what he's going for either, unless he's trying to coin a new term (in which case defining it would seem appropriate). Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Somebody pass the Charmin! I'm dumping core!! -- Black Widow 2.0.3 -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje file format breakage
Am Tue, 10 Aug 2010 06:12:16 +1000 schrieb David Seikel: On Mon, 09 Aug 2010 13:56:03 -0400 Christopher Michael cpmicha...@comcast.net wrote: On 08/09/2010 01:49 PM, Tom Hacohen wrote: If I remember correctly there are some edj (i.e already compiled edc's) in svn. Don't forget to update them, or better yet, create a Makefile for them and start shipping only edc's. That would be the preferred way (edc), so that future things like that do not require too much manual updating...the edj files can just be remade during the build process. I have always insisted that we store edc source files in SVN and not edj files. This is yet one more good reason to. Raster said that edj is an image format like PNG, but PNG is not compiled from source, so that argument is not a good one. edj files are compiled from source, so we should ALWAYS put the source in SVN and suitable makefiles to compile them. I couldn't agree that. Whats's about people creating edj files with editje? I've one application where I never wrote edc files. So how should I check in edc files in this case? Decompile before commit? :-) regards Andreas -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eterm selection_send() and Opera 10.60
On Mon, 09 Aug 2010 01:42:52 +0200, Michael Jennings m...@kainx.org wrote:
On Wednesday, 04 August 2010, at 22:37:21 (+0200),
Kim Woelders wrote:
I don't think there will be portability issues with this patch
unless you somehow get non-matching old Xlib/Xmu versions - not very
likely I'd say.
If I were in a cleaning mood I'd get rid of Xmu, which as far as I
can see only is used for
XA_TEXT/COMPOUND_TEXT/XA_UTF8_STRING(Xdisplay), which could easily
be replaced with some new props[...].
Can you elaborate on this idea?
I was thinking something like the attached patch.
Then I found XA_CLIPBOARD(Xdisplay). Assuming we have X11/Xmu/Atoms.h,
which I think practically always is true, XA_CLIPBOARD(Xdisplay) will
refer to the CLIPBOARD atom in screen.c (used in IS_SELECTION()) where
X11/Xmu/Atoms.h is included before screen.h, whereas
XA_CLIPBOARD(Xdisplay) will refer to the PRIMARY atom in script.c and
term.c due to definition in screen.h.
It is of course simple to add props[PROP_CLIPBOARD] too, but I'm not sure
what the intended behavior is.
...
Kim/Paolo, please comment on the patch I committed. Most importantly,
if/how to condense or eliminate the two XmbText...() cases.
I don't think there is much to gain by merging the two cases.
/KimFrom 1663a36499551dc7712e75b9810171ac92171c9f Mon Sep 17 00:00:00 2001
From: Kim Woelders k...@woelders.dk
Date: Mon, 9 Aug 2010 20:02:34 +0200
Subject: [PATCH] Remove dependency on Xmu.
diff --git a/configure.ac b/configure.ac
index 380bd11..745c0f8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -205,8 +205,7 @@ sys/ioctl.h sys/select.h sys/time.h \
sys/sockio.h sys/byteorder.h malloc.h \
utmpx.h unistd.h bsd/signal.h regex.h \
regexp.h stdarg.h X11/X.h X11/Xlib.h \
-X11/Xmu/Atoms.h X11/Sunkeysym.h \
-X11/Xlocale.h \
+X11/Sunkeysym.h X11/Xlocale.h \
)
AC_HEADER_TIME
@@ -872,11 +871,6 @@ AC_ARG_ENABLE(xim,
XIM=TRUE
])
-# For multibyte selection handling
-#if test $MULTICHAR_ENCODING != none; then
- AC_CHECK_LIB(Xmu, XmuInternAtom)
-#fi
-
# check X11R6 for XIM
if test $XIM = TRUE; then
AC_CHECK_LIB(X11, XRegisterIMInstantiateCallback, AC_DEFINE(USE_X11R6_XIM, , [Define if we have X11R6 XIM.]))
diff --git a/src/screen.c b/src/screen.c
index b4d6255..006856b 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -26,9 +26,6 @@ static const char cvs_ident[] = $Id$;
#include errno.h
#include X11/Xatom.h
#include X11/Xmd.h/* CARD32 */
-#ifdef HAVE_X11_XMU_ATOMS_H
-# include X11/Xmu/Atoms.h
-#endif
#include buttons.h
#include command.h
@@ -2596,9 +2593,9 @@ selection_paste(Atom sel)
form (usually XA_STRING) and save it for us in the VT_SELECTION
property. We'll then get a SelectionNotify. */
D_SELECT((Requesting current selection (%d) - VT_SELECTION (%d)\n, sel, props[PROP_SELECTION_DEST]));
-#if defined(MULTI_CHARSET) defined(HAVE_X11_XMU_ATOMS_H)
+#if defined(MULTI_CHARSET)
if (encoding_method != LATIN1) {
-XConvertSelection(Xdisplay, sel, XA_COMPOUND_TEXT(Xdisplay), props[PROP_SELECTION_DEST], TermWin.vt, CurrentTime);
+XConvertSelection(Xdisplay, sel, props[PROP_COMPOUND_TEXT], props[PROP_SELECTION_DEST], TermWin.vt, CurrentTime);
} else {
XConvertSelection(Xdisplay, sel, XA_STRING, props[PROP_SELECTION_DEST], TermWin.vt, CurrentTime);
}
@@ -3346,7 +3343,7 @@ selection_send(XSelectionRequestEvent * rq)
ev.xselection.property = rq-property;
#ifdef MULTI_CHARSET
# ifdef X_HAVE_UTF8_STRING
-} else if (rq-target == XA_UTF8_STRING(Xdisplay)) {
+} else if (rq-target == props[PROP_UTF8_STRING]) {
XTextProperty xtextp;
char *l[1];
@@ -3362,8 +3359,7 @@ selection_send(XSelectionRequestEvent * rq)
}
}
# endif /* X_HAVE_UTF8_STRING */
-# ifdef HAVE_X11_XMU_ATOMS_H
-} else if (rq-target == XA_TEXT(Xdisplay) || rq-target == XA_COMPOUND_TEXT(Xdisplay)) {
+} else if (rq-target == props[PROP_TEXT] || rq-target == props[PROP_COMPOUND_TEXT]) {
XTextProperty xtextp;
char *l[1];
@@ -3372,13 +3368,12 @@ selection_send(XSelectionRequestEvent * rq)
xtextp.nitems = 0;
if (XmbTextListToTextProperty(Xdisplay, l, 1, XCompoundTextStyle, xtextp) == Success) {
if (xtextp.nitems 0 xtextp.value != NULL) {
-XChangeProperty(Xdisplay, rq-requestor, rq-property, XA_COMPOUND_TEXT(Xdisplay),
+XChangeProperty(Xdisplay, rq-requestor, rq-property, props[PROP_COMPOUND_TEXT],
8, PropModeReplace, xtextp.value, xtextp.nitems);
ev.xselection.property = rq-property;
XFree(xtextp.value);
}
}
-# endif /* HAVE_X11_XMU_ATOMS_H */
#endif /* MULTI_CHARSET */
} else {
XChangeProperty(Xdisplay, rq-requestor, rq-property, XA_STRING, 8, PropModeReplace, selection.text, selection.len);
diff --git a/src/startup.c
Re: [E-devel] Edje file format breakage
On Monday, 09 August 2010, at 22:18:16 (+0200), Andreas Volz wrote: I couldn't agree that. Whats's about people creating edj files with editje? I've one application where I never wrote edc files. So how should I check in edc files in this case? Decompile before commit? Yes? Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- ...in order to secure the safety of the public while traveling on public roads...it shall be unlawful for any person to drive, propel, or run any vehicle in, upon, and along any of the public roads in this county. -- Montgomery County, Mississippi, statute -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] library todos
On Sun, Aug 8, 2010 at 1:12 AM, David Seikel onef...@gmail.com wrote: What is trators? An image speaks for more than a thousand words. How about around 6,390,000 images[1]? [1] http://bit.ly/9LIx0B Leandro -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] broken: elementary notify, pager pager slide...
it seems someone broke elm's notify, pager pager slide recently.. smells of an elm or edje break (changes to evas enignes dont affect this). who/what/where/when... and fix? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] library todos
On Tue, 10 Aug 2010, Tom Haste wrote: I think we should avoid having tractors in SVN too. Back to the original message though discomfitor has a very in depth TODO file in his dev/ folder. I think its a great idea as people know whats doing on in other peoples minds and maybe even some collaboration can come from it. sure. Look in devs/ the number of possible people that can commit. Think now of the number of TODO file to look at if you want to know what people are working on... Vincent -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] broken: elementary notify, pager pager slide...
On Tue, Aug 10, 2010 at 7:22 AM, Carsten Haitzler ras...@rasterman.com wrote: it seems someone broke elm's notify, pager pager slide recently.. smells of an elm or edje break (changes to evas enignes dont affect this). who/what/where/when... and fix? Could you describe a little it more the brokeness of that stuff and how I can reproduce it and what result is expected ? -- Cedric BAIL -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
