No worries; I don't take it personally, and I totally understand that the time had come. I actually agree! And I'll be the first to admit I've had higher priorities for my non-work time (kids change EVERYTHING); things would be greatly different if coding on E-related stuff comprised my day job. :-)
It's just important to keep a distinction between "upgrade" and "alternative" (or perhaps eventually "replacement") since the two are almost entirely unrelated (i.e., Eterm was merely used as a reference during the initial coding of Terminology). When I said "stable," I was referring to the fact that Eterm hasn't crashed on me in years...literally. Contrast that with Terminology, which crashed within minutes when I tried to use it. :-( Eventually, I hope, Terminology will be able to do everything Eterm can do (along with all the stuff it can already do that Eterm can't) and do it in a rock-solid manner. When that day comes, I too will switch! So please don't think I'm bothered by its existence or that I begrudge you the choice you made; I don't. You made the right call. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <m...@eterm.org> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) On Tue, Jul 29, 2014 at 4:08 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Tue, 29 Jul 2014 15:40:47 -0700 Michael Jennings <mjenni...@gmail.com> > said: > >> Thanks, Boris! I object to referring to Terminology as an "upgrade" >> to Eterm since they're completely different products (and Eterm is >> way, way more stable and more performant, at least for the time >> being), but I'll happily accept bug fixes. :-) > > one of them uses efl... the other does not. :) one of them is actively > developed... the other is not (i guess that is another way of saying... > stable :)). :) > > you know we don't hate you mej. :) the time had come for a terminal that > actually fit in e these days. i looked at "fixing" eterm. i rummaged through > its code. it was frankly just easier to start again. > >> Michael >> >> -- >> Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <m...@eterm.org> >> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) >> >> >> On Tue, Jul 29, 2014 at 11:38 AM, Boris Faure <bo...@fau.re> wrote: >> > On 14-07-29 17:52, Boris Faure wrote: >> >> On 14-07-29 16:23, sebastien.ponc...@m4x.org wrote: >> >> > Hi all, >> >> > >> >> > I've recently been enabled to use Eterm after an upgrade, because it >> >> > freezes on start. >> >> >> >> You should upgrade to Terminology :) >> >> >> >> > Using strace reveals that Eterm spends 100% CPU >> >> > closing all file descriptors from 0 to 65535 in a tight loop (it >> >> > restarts from 0 when reaching 65535). >> >> > Attaching in gdb gave me the culprit in the code : command.c lines >> >> > 1562 to 1679, reproduced here : >> >> > >> >> > /* >> >> > * Close all file descriptors. If only stdin/out/err are closed, >> >> > * child processes remain alive upon deletion of the window. >> >> > */ >> >> > { >> >> > unsigned short i; >> >> > unsigned long max_fds; >> >> > >> >> > /* get number of available file descriptors */ >> >> > #ifdef _POSIX_VERSION >> >> > max_fds = sysconf(_SC_OPEN_MAX); >> >> > #else >> >> > max_fds = getdtablesize(); >> >> > #endif >> >> > >> >> > D_TTY(("Closing file descriptors 0-%d.\n", max_fds)); >> >> > for (i = 0; i < max_fds; i++) { >> >> > if (i != fd) >> >> > close(i); >> >> > } >> >> > D_TTY(("...closed.\n")); >> >> > } >> >> > >> >> > Guess what happens if sysconf(_SC_OPEN_MAX) returns 65536.... >> >> > A simple fix is to change the declaration of i to unsigned int. Although >> >> > I'm not sure this loop is very efficient. >> >> >> >> It should be turned into unsigned long, just like max_fds. I'll make the >> >> patch tonight if nobody did it before. >> > >> > It's done, as a "long" since sysconf() returns a long and >> > getdtablesize() returns an int. >> > >> > -- >> > Boris Faure >> > Pointer Arithmetician >> > >> > ------------------------------------------------------------------------------ >> > Infragistics Professional >> > Build stunning WinForms apps today! >> > Reboot your WinForms applications with our WinForms controls. >> > Build a bridge from your legacy apps to the future. >> > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > enlightenment-devel mailing list >> > enlightenment-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> >> ------------------------------------------------------------------------------ >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
