[E-devel] Standards are good !
In the spirit of the Linux kernel (/usr/src/linux/scripts/Lindent), I am submitting this script that took me nearly two months to finish (j/k). Its goal is to provide a clear definition on how to format ones code before submission. Whether you like it or is irrelevant; I for one hate this style, but none the less stick to it or die a bloody death. voidengineer -- -- Ap Mechans Thes -- .-.Stephen Horner void.engineer(at)unix.net /v\AIMbeepbeepkaah // \\ MSNparse3rr0r(at)hotmail.com /( )\ PGP0xCDC2DD2B ^^-^^ --- #!/bin/sh indent -i3 -bl -bad -nbap -sob -ncdb -di20 -nbc -lp -nce -npcs -sc -ncs -l80 $@ pgpJgIgrTl6mC.pgp Description: PGP signature
[E-devel] Eterm SSE2 patch for x86_64
Michael, Tres asked me to help with the configure.in and Makefile.am bits for his SSE2 code for x86_64. I've attached patches against Eterm CVS with changes to: configure.in, src/Makefile.am, src/pixmap.c, and the new file: src/sse2_cmod.c (changed since Tres's earlier version) The configure.in changes add --enable-sse2 which will be on by default for x86_64. The incomplete tests for MMX_64 have been removed. There was an odd dps_snprintf_oflow() line in configure.in which was causing problems on my i686 system, and which I think was a typo, so I removed it. The src/Makefile.am changes just add the new source file sse2_cmod.c and conditionally compile it when HAVE_SSE2 is defined. The src/pixman.c changes add externs for the new sse2 function, and conditionals to use them if HAVE_SSE2 is defined. Tres also added 8 or 16 byte alignment conditionally to colormod_trans() - this should perhaps be done only for gcc? Tres indicated that adding -mpreferred-stack-boundary=16 might still be beneficial on x86_64, but that it might consume extra space at run time. I'm not in a position to make that call, but if you agree its a good idea I can probably make the configure.in change. I've tested the changes on xi686 and x86_64 and verified that the correct routines get compiled in. I verified that the modified Eterms run and that the Brightness control does something reasonable on both systems.I have not done any performance tests. All credit for the sse2_cmod.c code goes to Tres. I just did the easy bits. John Index: configure.in === RCS file: /cvsroot/enlightenment/eterm/Eterm/configure.in,v retrieving revision 1.92 diff -u -r1.92 configure.in --- configure.in 1 May 2005 07:16:51 - 1.92 +++ configure.in 6 Jun 2005 14:44:01 - @@ -220,7 +220,7 @@ seteuid memmove putenv strsep setresuid setresgid \ memmem usleep snprintf strcasestr strcasechr \ strcasepbrk strrev nl_langinfo) -dps_snprintf_oflow() + AC_CHECK_LIB(m, pow) dnl# Portability checks for various functions @@ -500,9 +500,11 @@ AC_DEFINE(PIXMAP_OFFSET, , [Define for pseudo-transparency support.]) ]) +dnl# +dnl# MMX support +dnl# AC_MSG_CHECKING(for MMX support) HAVE_MMX= -HAVE_MMX_64= AC_ARG_ENABLE(mmx, [ --enable-mmxenable MMX assembly routines], [ test x$enableval = xyes HAVE_MMX=yes ], [ @@ -510,25 +512,39 @@ i*86) grep mmx /proc/cpuinfo /dev/null 21 HAVE_MMX=yes ;; - x86_64) - grep mmx /proc/cpuinfo /dev/null 21 HAVE_MMX_64=yes - ;; esac ]) if test x$HAVE_MMX = xyes; then AC_MSG_RESULT([yes (32-bit)]) AC_DEFINE(HAVE_MMX, , [Define for 32-bit MMX support.]) -elif test x$HAVE_MMX_64 = xyes; then -dnl# AC_MSG_RESULT([yes (64-bit)]) -dnl# AC_DEFINE(HAVE_MMX_64, , [Define for 64-bit MMX support.]) -AC_MSG_RESULT([no (64-bit MMX not yet supported)]) else AC_MSG_RESULT([no (no MMX detected)]) fi -dnl# AM_CONDITIONAL(HAVE_MMX, test x$HAVE_MMX = xyes -o x$HAVE_MMX_64 = xyes) AM_CONDITIONAL(HAVE_MMX, test x$HAVE_MMX = xyes) dnl# +dnl# SSE2 support +dnl# +AC_MSG_CHECKING(for SSE2 support) +HAVE_SSE2= +AC_ARG_ENABLE(sse2, [ --enable-sse2enable SSE2 assembly routines], [ + test x$enableval = xyes HAVE_SSE2=yes + ], [ + case $host_cpu in + x86_64) + grep sse2 /proc/cpuinfo /dev/null 21 HAVE_SSE2=yes + ;; + esac + ]) +if test x$HAVE_SSE2 = xyes; then +AC_MSG_RESULT([yes]) +AC_DEFINE(HAVE_SSE2, , [Define for 64-bit SSE2 support.]) +else +AC_MSG_RESULT([no (no SSE2 detected)]) +fi +AM_CONDITIONAL(HAVE_SSE2, test x$HAVE_SSE2 = xyes) + +dnl# dnl# LibAST dnl# LIBAST_MIN=5 Index: src/Makefile.am === RCS file: /cvsroot/enlightenment/eterm/Eterm/src/Makefile.am,v retrieving revision 1.29 diff -u -r1.29 Makefile.am --- src/Makefile.am 15 Mar 2005 21:48:01 - 1.29 +++ src/Makefile.am 6 Jun 2005 14:44:01 - @@ -6,6 +6,9 @@ MMX_SRCS = mmx_cmod.S MMX_OBJS = mmx_cmod.lo +SSE2_SRCS = sse2_cmod.c +SSE2_OBJS = sse2_cmod.lo + libEterm_la_SOURCES = actions.c actions.h buttons.c buttons.h command.c \ command.h draw.c draw.h e.c e.h eterm_debug.h eterm_utmp.h \ events.c events.h feature.h font.c font.h grkelot.c\ @@ -16,22 +19,27 @@ timer.c timer.h utmp.c windows.c windows.h defaultfont.c \ defaultfont.h libscream.c scream.h screamcfg.h -EXTRA_libEterm_la_SOURCES = $(MMX_SRCS) +EXTRA_libEterm_la_SOURCES = $(MMX_SRCS)
[e-devel] ewl_progressbar, some new features
Hello!
While playing with some progressbars, I found myself dreaming about
some missing features... So I coded them :p
- First I added a char *label_format to struct Ewl_Progressbar, it is
set to %3$.0lf%% at initialization, to keep the default percentage
mode, as I changed label arguments to value, range, value/range*100,
range-value, (range-value)/range*100 (there shouldn't be anything that
could be useful missing now :p).
- ewl_progressbar_label_get: retrieves current label value
- ewl_progressbar_label_format_set: sets the default label format, so
that we don't have to call ewl_progressbar_custom_label_set at each
value update, that's a hassle less :)
- ewl_progressbar_label_format_get: do I have to explain what it's
supposed to do ;D
- ewl_progressbar_default_label_set: resets the label format to its
initial value, so %3$.0lf%% (maybe this name is not as good)
- some cosmetic changes (english error corrections)
- correction of default (winter) theme where the bottom of the
progressbar (the 'done' part) was not shown
Hope this is bugless (;D) and helpful...
Cheers!
--
ilLogict
Etudiant:1A, E.S.I.A.L., Nancy, France
Student: Y1, E.S.I.A.L., Nancy, France
Website: http://illogict.online.fr
E-Mail: [EMAIL PROTECTED]
ICQ: #74274856
AIM: illogict
MSN: [EMAIL PROTECTED]
Yahoo: illogict
Jabber: [EMAIL PROTECTED]
Mobile: +33 6 81921083
Message: Enlightenment DR17 oune ! Et honte ceux qui ne sont pas d'accord !
Message: Enlightenment DR17 rocks! Shame on whoever doesn't agree!Index: libs/ewl/data/themes/default/bits/progressbar-groups.edc
===
RCS file: /cvsroot/enlightenment/e17/libs/ewl/data/themes/default/bits/progressbar-groups.edc,v
retrieving revision 1.3
diff -u -r1.3 progressbar-groups.edc
--- libs/ewl/data/themes/default/bits/progressbar-groups.edc 1 Nov 2004 04:49:49 - 1.3
+++ libs/ewl/data/themes/default/bits/progressbar-groups.edc 6 Jun 2005 15:31:33 -
@@ -46,7 +46,7 @@
}
rel2 {
relative, 1.0 1.0;
- offset, -1 -1;
+ offset, -1 -3;
}
image {
normal, button-up.png;
Index: libs/ewl/src/bin/ewl_test.c
===
RCS file: /cvsroot/enlightenment/e17/libs/ewl/src/bin/ewl_test.c,v
retrieving revision 1.8
diff -u -r1.8 ewl_test.c
--- libs/ewl/src/bin/ewl_test.c 28 May 2005 20:32:49 - 1.8
+++ libs/ewl/src/bin/ewl_test.c 6 Jun 2005 15:31:33 -
@@ -78,10 +78,10 @@
{ Spinner, __create_spinner_test_window, ewl_spinner_test.c },
{ Statusbar, __create_statusbar_test_window, ewl_statusbar_test.c },
{ Table, __create_table_test_window, ewl_table_test.c },
- { Textarea,__create_textarea_test_window,ewl_textarea_test.c },
- { Theme, __create_theme_test_window, ewl_theme_test.c },
+ //{ Textarea,__create_textarea_test_window,ewl_textarea_test.c },
+ //{ Theme, __create_theme_test_window, ewl_theme_test.c },
{ Tooltip, __create_tooltip_test_window, ewl_tooltip_test.c },
- { Tree,__create_tree_test_window,ewl_tree_test.c },
+ //{ Tree,__create_tree_test_window,ewl_tree_test.c },
{ 0, 0, 0 }
};
static char* tooltips[] = {
@@ -227,6 +227,7 @@
* Add the row to the tree, and setup it's alignment and
* fill.
*/
+ printf(%d\n,i);
prow[i] = ewl_tree_text_row_add( EWL_TREE (main_tree), NULL,
(tests[i].name));
ewl_callback_append (EWL_WIDGET (prow[i]),
Index: libs/ewl/src/lib/ewl_progressbar.c
===
RCS file: /cvsroot/enlightenment/e17/libs/ewl/src/lib/ewl_progressbar.c,v
retrieving revision 1.2
diff -u -r1.2 ewl_progressbar.c
--- libs/ewl/src/lib/ewl_progressbar.c 28 Mar 2005 07:04:29 - 1.2
+++ libs/ewl/src/lib/ewl_progressbar.c 6 Jun 2005 15:31:33 -
@@ -6,7 +6,7 @@
/**
* @return Returns NULL on failure, or a pointer to the new progressbar on success.
- * @brief Allocate and initialize a new progressbar
+ * @brief Allocates and initializes a new progressbar.
*/
Ewl_Widget *ewl_progressbar_new()
{
@@ -26,7 +26,7 @@
/**
* @param p: the progressbar to be initialized
* @return Returns no value.
- * @brief Initialize the progressbar to some sane starting values
+ * @brief Initializes the progressbar to some sane starting values.
*/
void ewl_progressbar_init(Ewl_Progressbar * p)
{
@@ -64,6 +64,10 @@
p-value = 0.0;
p-range = 100.0;
p-auto_label = TRUE;
+ /*
+ * Do a percentage calculation as a default label.
+ */
+ p-label_format = strdup(%3$.0lf%%);
ewl_callback_append(w, EWL_CALLBACK_CONFIGURE,
ewl_progressbar_configure_cb, NULL);
@@ -74,9 +78,9 @@
/**
* @param p: the progressbar whose value will be changed
- * @param v: the new value of the statusbar
+ * @param v: the new value of the progressbar
* @return
RE: [e-devel] ewl_progressbar, some new features
Hello, Few comments on the patch. - Any reason why you commented out a bunch of the tests? - Should use const for the char * parameters. - if this does the same thing as the custom label, i'd be preferable to just use the custom label stuff instead of creating all new routines. - if you have a format of %3$.0lf%% how can you write 4 differnt thigns into it? or are you depending on that just being ignored since it isn't used? Thats pretty nasty behaviour, in my opinion. dan Hello! While playing with some progressbars, I found myself dreaming about some missing features... So I coded them :p - First I added a char *label_format to struct Ewl_Progressbar, it is set to %3$.0lf%% at initialization, to keep the default percentage mode, as I changed label arguments to value, range, value/range*100, range-value, (range-value)/range*100 (there shouldn't be anything that could be useful missing now :p). - ewl_progressbar_label_get: retrieves current label value - ewl_progressbar_label_format_set: sets the default label format, so that we don't have to call ewl_progressbar_custom_label_set at each value update, that's a hassle less :) - ewl_progressbar_label_format_get: do I have to explain what it's supposed to do ;D - ewl_progressbar_default_label_set: resets the label format to its initial value, so %3$.0lf%% (maybe this name is not as good) - some cosmetic changes (english error corrections) - correction of default (winter) theme where the bottom of the progressbar (the 'done' part) was not shown Hope this is bugless (;D) and helpful... Cheers! -- ilLogict Etudiant:1A, E.S.I.A.L., Nancy, France Student: Y1, E.S.I.A.L., Nancy, France Website: http://illogict.online.fr E-Mail: [EMAIL PROTECTED] ICQ: #74274856 AIM: illogict MSN: [EMAIL PROTECTED] Yahoo: illogict Jabber: [EMAIL PROTECTED] Mobile: +33 6 81921083 Message: Enlightenment DR17 oune ! Et honte ceux qui ne sont pas d'accord ! Message: Enlightenment DR17 rocks! Shame on whoever doesn't agree! --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: libast from Eterm CVS fails to build with gcc4 on x86_64
On Thursday, 02 June 2005, at 15:56:40 (-0400),
John Ellson wrote:
RCS file: /cvsroot/enlightenment/eterm/libast/configure.in,v
retrieving revision 1.24
Got it, thanks.
On Thursday, 02 June 2005, at 16:02:00 (-0400),
Mike Frysinger wrote:
would an ifdef like:
#if STRICT_ISO_C99 || __GNUC__ 4
be unacceptable ? that way the installed libast wouldnt need to be
reconfigured/built/installed just to change STRICT_ISO_C99 ...
How about this:
#ifdef __GNUC__
# if __GNUC__ = 4
#define STRICT_ISO_C99
# fi
...
#endif
On Thursday, 02 June 2005, at 18:39:01 (-0600),
Tres Melton wrote:
#define BINSWAP(a, b) \
(((long) (a)) ^= ((long) (b)) ^= ((long) (a)) ^= ((long) (b)))
int main( void )
{
long a = 3;
long b = 8;
asm( noop;noop;noop );
BINSWAP(a,b);
asm( noop;noop;noop );
}
yields:
noop;noop;noop
movq-16(%rbp), %rdx
leaq-8(%rbp), %rax
xorq%rdx, (%rax)
movq-8(%rbp), %rdx
leaq-16(%rbp), %rax
xorq%rdx, (%rax)
movq-16(%rbp), %rdx
leaq-8(%rbp), %rax
xorq%rdx, (%rax)
noop;noop;noop
If you enable -O[123] then you will need to use the values a b before
and after the BINSWAP call or they will be optimized away. And simply
using immediate values like I did will cause the compiler to simply set
the different registers that are used to access them in reverse order.
In other words the swap gets optimized out. The above code is without
-O and is clearly more complicated (by more than double) than it needs
to be.
Interesting. You think I should just get rid of it then?
On Thursday, 02 June 2005, at 21:04:59 (-0400),
John Ellson wrote:
I understand that this is a ISO C99 restriction and that gcc4 is
just a bit more pedantic than gcc3.
gcc4 does C99 by default now, does it not?
In fact my first attempt at a fix was to just not use the xor
BINSWAP macro at all, but this is really a question for Michael. I
was just trying to get his code to compile.
It's actually slower normally but faster optimized:
-O0
Profiling SWAP() macro...300 iterations in 0.052468 seconds, 1.7489e-08
seconds per iteration
Profiling BINSWAP() macro...300 iterations in 0.067905 seconds, 2.2635e-08
seconds per iteration
-O2
Profiling SWAP() macro...300 iterations in 0.014328 seconds, 4.776e-09
seconds per iteration
Profiling BINSWAP() macro...300 iterations in 0.014183 seconds, 4.7277e-09
seconds per iteration
(Done with libast's make perf)
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED]
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
---
There is a greater darkness than the one we fight. It is the
darkness of a soul that has lost its way. -- G'Kar, Babylon 5
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Patch for eclair shuffle
Enlightenment developers,
I couldn't find a mailing list or website specific to eclair, so I'm
sending the patch here. I apologize if this is the wrong place...
As the name would imply, the patch adds playlist shuffling to eclair.
--
Kevin Webb
Computer Science
Georgia Institute of Technology
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity. -Dennis Ritchie
Index: data/glade/eclair.glade
===
RCS file: data/glade/eclair.glade,v
retrieving revision 1.2
diff -b -u -2 -r1.2 eclair.glade
--- data/glade/eclair.glade 27 May 2005 21:31:48 - 1.2
+++ data/glade/eclair.glade 6 Jun 2005 04:24:25 -
@@ -254,4 +254,28 @@
/widget
/child
+
+ child
+widget class=GtkMenuItem id=options1
+ property name=visibleTrue/property
+ property name=label translatable=yesOptions/property
+ property name=use_underlineTrue/property
+ signal name=activate handler=on_options1_activate
last_modification_time=Sun, 05 Jun 2005 23:24:01 GMT/
+
+ child
+ widget class=GtkMenu id=options1_menu
+
+ child
+ widget class=GtkCheckMenuItem id=toggle_shuffle1
+ property name=visibleTrue/property
+ property name=label translatable=yesShuffle/property
+ property name=use_underlineTrue/property
+ property name=activeFalse/property
+ signal name=activate handler=toggle_shuffle_handler
last_modification_time=Sun, 05 Jun 2005 23:24:01 GMT/
+ /widget
+ /child
+ /widget
+ /child
+/widget
+ /child
/widget
Index: src/eclair.c
===
RCS file: src/eclair.c,v
retrieving revision 1.19
diff -b -u -2 -r1.19 eclair.c
--- src/eclair.c27 May 2005 20:28:22 - 1.19
+++ src/eclair.c6 Jun 2005 04:24:26 -
@@ -32,4 +32,5 @@
Evas_List *filenames, *l;
filenames = NULL;
+ int shuffle = 0;
if (!eclair)
@@ -72,4 +73,6 @@
eclair_dialogs_init(eclair-dialogs_manager, eclair);
eclair_playlist_init(eclair-playlist, eclair);
+ if (eclair_config_get_prop_int(eclair-config, shuffle, on, shuffle))
+ eclair-playlist.shuffle = shuffle;
eclair_playlist_container_set_media_list(eclair-playlist_container,
eclair-playlist.playlist);
eclair_subtitles_init(eclair-subtitles);
@@ -110,4 +113,9 @@
}
+ if (eclair-playlist)
+ {
+ eclair_config_set_prop_int(eclair-config, shuffle, on,
eclair-playlist.shuffle);
+ }
+
fprintf(stderr, Eclair: Debug: Destroying create video object
thread\n);
pthread_join(eclair-video_create_thread, NULL);
@@ -372,5 +380,12 @@
return;
+ if (eclair-playlist.shuffle)
+ {
+ eclair_playlist_random_as_current(eclair-playlist);
+ }
+ else
+ {
eclair_playlist_next_as_current(eclair-playlist);
+ }
eclair_play_current(eclair);
}
Index: src/eclair_config.c
===
RCS file: src/eclair_config.c,v
retrieving revision 1.8
diff -b -u -2 -r1.8 eclair_config.c
--- src/eclair_config.c 27 May 2005 20:28:22 - 1.8
+++ src/eclair_config.c 6 Jun 2005 04:24:26 -
@@ -71,4 +71,5 @@
eclair_config_set_prop_int(config, gui_window, x, 0);
eclair_config_set_prop_int(config, gui_window, y, 0);
+ eclair_config_set_prop_int(config, shuffle, on, 0);
}
Index: src/eclair_dialogs.c
===
RCS file: src/eclair_dialogs.c,v
retrieving revision 1.9
diff -b -u -2 -r1.9 eclair_dialogs.c
--- src/eclair_dialogs.c29 May 2005 09:27:28 - 1.9
+++ src/eclair_dialogs.c6 Jun 2005 04:24:26 -
@@ -28,4 +28,6 @@
static void _eclair_dialogs_menu_on_remove_all(GtkWidget *widget, gpointer
data);
+static void _eclair_dialogs_options_on_toggle_shuffle(GtkWidget *widget,
gpointer data);
+
//Initialize dialogs manager
void eclair_dialogs_init(Eclair_Dialogs_Manager *dialogs_manager, Eclair
*eclair)
@@ -147,4 +149,5 @@
Eclair_Dialogs_Manager *dialogs_manager;
Eclair *eclair;
+ GtkWidget *shuffle_toggle;
if (!(eclair = param))
@@ -166,4 +169,9 @@
glade_xml_signal_connect_data(dialogs_manager-menu_xml,
remove_all_handler, G_CALLBACK(_eclair_dialogs_menu_on_remove_all), eclair);
+ glade_xml_signal_connect_data(dialogs_manager-menu_xml,
toggle_shuffle_handler,
G_CALLBACK(_eclair_dialogs_options_on_toggle_shuffle), eclair);
+
+ shuffle_toggle = glade_xml_get_widget(dialogs_manager-menu_xml,
toggle_shuffle1);
+ gtk_check_menu_item_set_active((GtkCheckMenuItem *) shuffle_toggle,
eclair-playlist.shuffle);
+
g_timeout_add(50, _eclair_dialogs_update, dialogs_manager);
@@ -423,2 +431,20 @@
eclair_playlist_empty(eclair-playlist);
}
+
+//---
+//Options
+//---
+static void
Re: [E-devel] Re: libast from Eterm CVS fails to build with gcc4 on x86_64
On Monday 06 June 2005 07:09 pm, Tres Melton wrote:
The nop is just an easy way to place markers in the code so you
can find the interesting parts quickly. In reality it costs one clock
cycle for each nop.
i use asm label tricks:
$ cat test.c
int main(int argc, char *argv[])
{
int a;
asm(startit:);
a = 10;
asm(stopit:);
return 0;
}
$ gcc -c test.c objdump -d test.o
test.o: file format elf64-x86-64
Disassembly of section .text:
main:
0: 55 push %rbp
1: 48 89 e5mov%rsp,%rbp
4: 89 7d fcmov%edi,0xfffc(%rbp)
7: 48 89 75 f0 mov%rsi,0xfff0(%rbp)
000b startit:
b: c7 45 ec 0a 00 00 00movl $0xa,0xffec(%rbp)
0012 stopit:
12: b8 00 00 00 00 mov$0x0,%eax
17: c9 leaveq
18: c3 retq
-mike
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eterm SSE2 patch for x86_64
On Mon, 2005-06-06 at 11:28 -0400, John Ellson wrote: All credit for the sse2_cmod.c code goes to Tres. I just did the easy bits. Thanks, but the real credit goes to Willem Monsuwe [EMAIL PROTECTED] for writing the original MMX code. All I did was expand it to use all 128 bits of the xmm registers via SSE2 and make it inline so that it can handle whatever optimizations are thrown at gcc. It should be twice as fast as the original MMX since it processes twice as many pixels at once. Thanks for the work John, -- Tres --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E17 Debuging
(I forgot to switch to my subscribed email address when sending this message so hopefully there isn't a duplicate message later if a moderator passes it) I'm curious how other people attach a debugger to E17. Currently I've made a X11 session which looks like this. Eterm -e startx -- :1 sleep 6 Eterm -e gdb /usr/local/bin/enlightenment_e17 `ps -C enlightenment_e17 -o pid=` enlightenment (Note: I have --program-suffix=_e17 to identify it in the process list from e16) One nuisance is that once gdb attaches it locks E17 and you need to switch to your first display and type continue in the gdb terminal. The other problem is that with Eterm once the command is finished executing the terminal closes. So if there was any debug information you wanted from a clean closing session it'd be gone. This could be fixed by sending the output to a file, but it'd be nice if the terminal didn't close after the command. (Maybe other terminals behave differently but I haven't checked) One other issue is that restarting E will lose gdb and lock E. You have to quit your gdb session for E to be able to restart and then reattach a new gdb. I've looked at the gdb man page and couldn't find a way to automatically continue after attaching. I'm curious if there are options I'm missing or another way of doing this. Do any of you use a debugger other than gdb that is nicer to the program it is debugging? -Arlo --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 Debuging
On Mon, 06 Jun 2005 20:09:43 -0700 Arlo [EMAIL PROTECTED] babbled: (I forgot to switch to my subscribed email address when sending this message so hopefully there isn't a duplicate message later if a moderator passes it) I'm curious how other people attach a debugger to E17. Currently I've made a X11 session which looks like this. Eterm -e startx -- :1 sleep 6 Eterm -e gdb /usr/local/bin/enlightenment_e17 `ps -C enlightenment_e17 -o pid=` enlightenment (Note: I have --program-suffix=_e17 to identify it in the process list from e16) One nuisance is that once gdb attaches it locks E17 and you need to switch to your first display and type continue in the gdb terminal. The other problem is that with Eterm once the command is finished executing the terminal closes. So if there was any debug information you wanted from a clean closing session it'd be gone. This could be fixed by sending the output to a file, but it'd be nice if the terminal didn't close after the command. (Maybe other terminals behave differently but I haven't checked) One other issue is that restarting E will lose gdb and lock E. You have to quit your gdb session for E to be able to restart and then reattach a new gdb. I've looked at the gdb man page and couldn't find a way to automatically continue after attaching. I'm curious if there are options I'm missing or another way of doing this. Do any of you use a debugger other than gdb that is nicer to the program it is debugging? i test stuff in xnest - and launch another e17 process under gdb or valgrind (or both) :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
